fix(serializer): discriminated input patch fix

[aurimasrimkusnfq]

Q	A
Branch?	4.3
Tickets	Fixes #8414
License	MIT
Doc PR	N/A

Additional merge PATCH fix on top of #8424

[soyuka]

Thanks — reviewed this against #8424 and this PR supersedes it: your branch already carries soyuka's commit 761563f as its first commit, and generalizes it to cover the PATCH path that #8424 provably misses (at AbstractItemNormalizer.php:267 the discriminator resolution is skipped entirely when objectToPopulate !== null, so the $context['resource_class'] !== $type guard never fires). #8424 will be closed as superseded once this lands — authorship is preserved either way.

One change requested before merge:

$concreteClass = null !== $objectToPopulate ? $objectToPopulate::class : $type;

Please use $this->getObjectClass($objectToPopulate) instead of $objectToPopulate::class.

AbstractItemNormalizer pulls in ClassInfoTrait (:68) specifically to unwrap Doctrine proxies, and uses it everywhere else it needs a class name — :91, :106, :149. With input: SomeEntity::class where the provider returns a managed reference, ::class yields Proxies\__CG__\SomeEntity, which then gets pinned into $context['resource_class'] and breaks every downstream propertyMetadataFactory->create() call. Narrow scenario, but it is exactly what the helper exists to prevent.

Non-blocking, but worth a look while you are in there: the new Patch on ChannelResource declares output: NotificationChannelInput::class while processPatch() returns a ChannelResource. That looks incoherent and unrelated to the input-side bug — is it load-bearing for the test, or carried over from your application?