fix(doctrine): do not replace new relations with assigned ids by refe…

[dylan-rumble]

Q	A
Branch?	4.3
Tickets	Fixes #8438
License	MIT
Doc PR	n/a

Problem

When using the ObjectMapper (stateOptions + input DTO), PersistProcessor::handleLazyObjectRelations() replaces every unmanaged related object holding a non-null identifier with a getReference() proxy, assuming "has an id" means "row exists in the database".

That assumption only holds for #[ORM\GeneratedValue] entities (id is null pre-flush). With application-assigned identifiers (e.g. UUIDs), a freshly mapped nested entity is indistinguishable from a reference to an existing row: it gets swapped for a proxy, the proxy counts as managed, cascade: ['persist'] never fires, and the flush fails with a foreign key violation (or, on SQLite, the entity is "not found" on refresh).

Fix

Before creating a reference, ask the unit of work whether the object is genuinely new (UnitOfWork::getEntityState() for ORM, getDocumentState() for ODM) and skip it if it is STATE_NEW. Doctrine's own semantics give the right behavior for each case:

• DB-generated ids → STATE_DETACHED without any lookup → still replaced by a reference (the [Docs/DX] Clarify and simplify DTO-to-Entity relationship mapping with stateOptions and ObjectMapper #7689 IRI case is unchanged).
• Application-assigned ids, row exists → identity map / DB lookup → STATE_DETACHED → replaced by a reference.
• Application-assigned ids, row does not exist → STATE_NEW → left alone so cascade persist inserts it.

Tests

New Issue8438* fixtures (owning TaskRule with cascade: ['persist'] to TaskRuleCondition, both keyed by application-assigned UUIDs) and two functional tests in StateOptionTest:

• testPostWithEntityClassOptionCascadePersistsNewRelationWithAssignedIdentifier — nested condition payload with a pre-assigned UUID. Failed before this fix, passes now.
• testPostWithEntityClassOptionReferencesExistingRelationWithAssignedIdentifier — condition given as an IRI to an existing UUID-keyed row still resolves to a reference (no duplicate insert).

Note on the fixtures

The issue's example assigns the UUID in the entity constructor. With symfony/object-mapper ≥ 8.1, nested mapped targets are lazy ghosts whose initializer calls $mapper->map($value, $target) when the mapper is decorated (API Platform decorates it via api_platform.object_mapper.relation). That path never passes constructTarget, so the nested entity's constructor is never executed and a constructor-assigned id is never set. This cannot be detected downstream (isUninitializedLazyObject() is already false inside the initializer) and is a separate upstream object-mapper concern. The fixtures therefore assign the UUID in the DTO constructor, which exercises the exact PersistProcessor heuristic this PR fixes; the entity constructors still assign a UUID as in the issue.