Investigation: remaining model-building items require non-surgical reworks

[Copilot]

Tracking issue with three unchecked items in EF Core's relationship-building engine. I verified all three are still present and tested whether each can be fixed surgically. No code changes are shipped — empirically, the straightforward fixes regress, and the correct fixes need design direction. Findings below.

1. HasForeignKey sets FK properties after creating FK

InternalEntityTypeBuilder.HasForeignKey (private, ~L2612) creates the relationship with conventional shadow properties via HasRelationshipInternal, then sets the real properties in a second pass.

Threading dependentProperties into HasRelationshipInternal → CreateForeignKey (single-step creation) breaks 7 tests in InternalEntityTypeBuilderTest/InternalForeignKeyBuilderTest:

• Check.DebugAssert failed: FK not found — SetOrAddForeignKey asserts instead of matching a pre-existing FK in the hierarchy.
• principal key resolves to {TempId, TempId1} instead of reusing existing {Id, Unique}.
• derived FK not promoted (2 FKs instead of 1).

The richer InternalForeignKeyBuilder.HasForeignKey path does FK matching/promotion and principal-key reuse that the creation path lacks. A correct fix moves that logic into creation — a rework, not surgical.

2. Pass in principal type when attaching FK

RelationshipSnapshot.Attach / InternalForeignKeyBuilder.Attach receive only the dependent type and re-resolve the principal heuristically (InternalForeignKeyBuilder.cs ~L3499–3540). Threading the principal through widens Attach across many call sites and transient detach→reattach snapshots; the re-resolution exists for the principal-not-in-model case, so a naive parameter has limited value.

3. Inverting identifying FK to derived moves the FK to base

Invert branch of SetRelatedTypes (InternalForeignKeyBuilder.cs ~L1440–1441): dependentEntityType.LeastDerivedType(Metadata.PrincipalEntityType) walks up to the base. The "moves to base" mechanism reproduces, but in every scenario I could build it matches the intended least-derived placement and the inverted FK is no longer identifying — no unambiguous bug to anchor a regression-safe fix.

Asks for the reviewer

• Added inital solution structure, early metadata support, and utilities. #1: should SetOrAddForeignKey/CreateForeignKey absorb the FK matching/promotion currently in InternalForeignKeyBuilder.HasForeignKey?
• Metadata #3: a concrete model snippet where inverting an identifying FK to a derived type wrongly lands on the base — enough to pin a failing test and a targeted fix.