PROD-2446: make companion-field reference scanning schema-driven

[5PK]

Summary

Fixes PROD-2446 — a follow-up audit after PROD-2431/2435/2442 found that the schema-driven companion-field fix landed in ContentFieldMapper only, while two sibling utilities that scan the exact same content-item field data for other purposes were never updated to match. Both still assumed a linked-content reference is only ever shaped as a contentid/contentID/sortids object key, with no knowledge of a Content-typed field's LinkeContentDropdownValueField/SortIDFieldName companion setting.

Depends on #207 (PROD-2431/2435/2442) — this branches off PROD-2431, which is not yet merged, so this diff includes that PR's commits until it lands. The actual new work here is the final commit (PROD-2446: ...); the diff will shrink to just that once #207 merges to main.

1 — PROD-2309 guard is blind to companion fields

has-unresolved-content-references.ts → collectUnresolvedContentReferences() only recognized contentid/contentID/sortids keys. Called from content-batch-processor.ts (~line 416) before the field mapper runs, as the guard whose whole purpose is to throw before shipping a payload guaranteed to fail server-side with a NullReferenceException. sourceModel was already in scope at that call site but was never passed to the guard.

Worse: ContentFieldMapper.mapContentFields() (called right after) does find the companion field via the schema-driven pass, but when the reference can't be resolved it only increments a warning, not an error — and content-batch-processor.ts only logs validationErrors, never warnings. So an item with an unresolved companion-field reference sailed past the guard entirely and shipped to target with a dangling source ID — reproducing the exact opaque NullReferenceException PROD-2309 was built to prevent, via the companion-field path instead of the plain contentid/sortids path.

2 — Push-order dependency detection is blind to companion fields

collect-content-id-references.ts feeds get-content-item-types.ts's push-order logic (an item another item depends on is promoted to push first, so its source→target mapping exists in time). Same structural-only sniffing — collectContentIDReferences() didn't even take a model parameter, so it couldn't consult companion settings without a signature change. An item that references another item only through a companion field was never promoted to push-first, which can produce exactly the unresolved-reference scenario in #1.

Fix

• Extracted the companion-field-pair lookup (previously a private method inside ContentFieldMapper) into a shared src/lib/content/linked-content-companion-fields.ts (getLinkedContentCompanionFields/findFieldKey), so there's one source of truth instead of three near-duplicates.
• collectUnresolvedContentReferences() now accepts the source model and also checks each Content field's companion column (only at the top level — companions are always siblings of the main field, never nested).
• collectContentIDReferences() now accepts the source model too; get-content-item-types.ts resolves each item's own source model via modelMapper (mirroring the existing hasValidMappings pattern) to supply it.
• content-batch-processor.ts now passes sourceModel into the PROD-2309 guard call.

Testing

• New regression tests in collect-content-id-references.test.ts and has-unresolved-content-references.test.ts: arbitrarily-named companion, SortIDFieldName companion, sentinel/no-model back-compat, and (for the unresolved-reference guard) case-insensitive match and top-level-only scanning.
• New test in get-content-item-types.test.ts proving an item referenced only through a companion field is promoted to linkedContentItems (push-first).
• Full suite: npm test — 105 suites / 1924 tests passing, no regressions.
• npm run build — compiles clean.

🤖 Generated with Claude Code