RelationFieldSchemaDecorator applies the root class's relation hints to foreign definitions #11

Problem

RelationFieldSchemaDecorator::buildSchema() walks every entry of $schema->getDefinitions() and decorates iri-reference properties using the Doctrine metadata of the root $className — without checking which class a definition actually belongs to.

As far as I can tell, API Platform's OpenApiFactory builds all operations into one shared definitions object. If that holds, each buildSchema() call re-decorates every definition collected so far, not just the ones embedded in the current resource:

• two resources with a same-named relation (parent, owner, menu, …) pointing at different targets → array_merge() overwrites the hints, and whichever class was built last wins
• a definition of resource B gets x-collection / x-resource-class from resource A's association

The behaviour predates #10, but #10 runs the decorator for output schemas too, so it now affects more definitions.

Impact

• type-ahead lists members of the wrong collection
• with iri-reference: link to the related record in read-only state jedison-extender-bundle#2 (link to the related record in read-only state) it would navigate to a record of the wrong resource type

Proposal

• resolve the class per definition instead of using the root class — e.g. only decorate the definition(s) the current buildSchema() call produced (diff the definition keys before/after the decorated call), or map the definition key back to its resource short name
• skip a property that already carries x-collection (explicit configuration and earlier, correct decoration win)
• add a unit test with a mocked SchemaFactoryInterface: two classes, same relation name, different targets → each definition keeps its own hints

Acceptance

• every iri-reference property carries hints derived from the class that owns it
• covered by a test