Decide: an export that would clear a target's naming or required attribute should refuse-and-report, not fail-and-retry

[JayVDZ]

The question

When JIM's resolved state says a target attribute should be cleared, and that attribute is what names the entry (an LDAP RDN attribute such as uid or cn) or is required by the entry's object class (sn on inetOrgPerson), the directory can never grant the request while the entry exists. Today the export sends it anyway: the whole export is rejected in one instruction (taking every other change down with it), retried to its MaxRetries limit, and reported as InvalidGeneratedExternalId/UnhandledError, which names nothing an administrator can act on.

Should JIM instead decline the impossible part at the export boundary: keep the entry at its current DN, retain the naming/required values, apply the rest of the export, and record one advisory item naming the attribute and what to do about it?

Context

Found via #1603, where a misconfigured integration scenario produced the situation. The scenario is being fixed; a correctly-configured deployment anchors deprovisioning on the authoritative source and never recalls identity-critical target attributes. This issue is about the defence in depth: the situation remains reachable by real configuration (WhenLastConnectorDisconnected on a provisioning type with a partial secondary source, or any Attribute Flow change that stops supplying a naming attribute), and the current failure mode is a permanently unsatisfiable Pending Export.

What was prototyped (and withdrawn, pending this decision)

A working implementation existed during the #1603 investigation and was discarded when the root cause moved to the scenario. Its shape, for whoever picks this up:

• LdapConnectorExport: in both update paths, a new DN whose leftmost RDN alone is empty (the recalled-naming-attribute signature) suppresses the rename and records an advisory; a DN malformed anywhere else (an empty container component) still fails the export, because that is configuration to fix. ConsolidateModifications already excludes the current DN's RDN attribute from the modify, so keeping the current DN also keeps the naming value.
• ConnectedSystemExportResult.AdvisoryMessage / ProcessedExportItem.AdvisoryMessage: a success that must still be told to the administrator; carried through ExportExecutionServer to a new ActivityRunProfileExecutionItemErrorType.NamingAttributeRetained RPEI (the UnresolvedReference precedent: Activity completes with a warning, nothing retried).
• Not built, and needed for completeness if this proceeds: the same treatment for schema-required attributes (ConnectedSystemObjectTypeAttribute.Required already records MUST at schema import), since clearing sn fails with an object class violation one step after the rename is dealt with.
• Red-first NUnit coverage existed for all of the above at the connector boundary.

Not in scope

Whether "does a source remain" should be asked per attribute rather than per object (#1570's gate is object-level, so a source contributing three training fields keeps recall live for a surname it never supplied). That is a separate design conversation if it is wanted at all; the doctrine answer is that complementary sources should not contribute identity-critical target attributes in the first place.

References

• Scenario 1 anchors deprovisioning on the wrong rule; leaver recall wipes identity and breaks the export #1603 (the trigger; carries the full diagnosis history)
• Sync obsoletion's grace-period freeze can leave sole-contributed values with severed provenance on surviving Metaverse Objects #1570 / 41e2311 (the recall model and its three situations)
• docs/concepts/attribute-priority.md