Fix inverting identifying FK using wrong type and short-circuit principal type on attach

[Copilot]

Fixes two long-standing issues in EF Core's relationship-building engine.

1. Pass in principal type when attaching FK

RelationshipSnapshot now captures PrincipalEntityType and forwards it to InternalForeignKeyBuilder.Attach, which gains an optional EntityType? principalEntityType parameter. When the principal is known and still in the model, Attach short-circuits the heuristic re-resolution (InternalForeignKeyBuilder.cs ~L3499–3540), improving perf. The short-circuit matches on ClrType only for non-shared types to avoid colliding distinct shared-type entities; the existing re-resolution remains for the principal-not-in-model case.

Regression tests added in InternalForeignKeyBuilderTest:

• Attach_uses_provided_principal_type_when_in_model — verifies the short-circuit fires when the captured principal is still in the model.
• Attach_does_not_bind_to_wrong_shared_type_principal_by_clr_type — registers two shared-type entities with the same CLR type; passing the wrong one must not cause incorrect binding (the !HasSharedClrType guard disables CLR-type matching for shared types).
• Attach_falls_back_to_model_lookup_when_provided_principal_is_not_in_model — verifies the heuristic fallback correctly resolves the principal when the captured entity is stale.

2. Inverting identifying FK to derived no longer moves the FK to base

The invert branch of SetRelatedTypes (InternalForeignKeyBuilder.cs ~L1440–1441) used LeastDerivedType, which collapsed onto the base when the requested type was a proper base of the old opposite end. This is the bug: inverting an identifying FK between a non-derived type and a derived type produced an FK between two non-derived types. The invert branch now keeps the more-derived end, so the inverted FK stays between the derived and non-derived type. Added regression test Inverting_identifying_relationship_keeps_derived_dependent.

[AndriySvyryd]

@copilot Feel free to enhance the logic in SetOrAddForeignKey/CreateForeignKey, but make sure that this doesn't add code duplication
Pass in principal type when attaching FK when known to short-circuit logic and improve perf.
Find a scenario where there's an identifying FK between a non-derived type and a derived type where inverting it makes it go from non-derived type to non-derived type, this is the bug. The inverted FK should be between a derived type and a non-derived type

[Copilot]

Pull request overview

This PR is presented as an investigation into remaining relationship/model-building behaviors in EF Core, but it also includes code changes that alter the attach/snapshot plumbing for relationships.

Changes:

• Capture and store the relationship’s principal entity type in RelationshipSnapshot.
• Thread the captured principal entity type into InternalForeignKeyBuilder.Attach via a new optional parameter.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/EFCore/Metadata/Internal/RelationshipSnapshot.cs	Stores PrincipalEntityType on snapshot creation and passes it into Relationship.Attach(...) during reattach.
src/EFCore/Metadata/Internal/InternalForeignKeyBuilder.cs	Extends Attach to accept an optional principalEntityType and prefers it when it appears valid/in-model.

[Copilot]

@copilot Feel free to enhance the logic in SetOrAddForeignKey/CreateForeignKey, but make sure that this doesn't add code duplication
Pass in principal type when attaching FK when know...

All three items are now implemented (the previous PR shipped no code):

• 1 (single-step FK creation): InternalEntityTypeBuilder.HasForeignKey threads the dependent properties through HasRelationshipInternal/CreateForeignKey/SetOrAddForeignKey, so the FK is created with the real properties instead of conventional shadow properties followed by a replace. To avoid duplicating the FK matching/promotion in InternalForeignKeyBuilder.HasForeignKey, SetOrAddForeignKey falls back to shadow-property creation when a matching FK already exists in the hierarchy, leaving the match/promotion to the existing path.
• 2 (pass principal type when attaching): RelationshipSnapshot captures PrincipalEntityType and forwards it to InternalForeignKeyBuilder.Attach, which short-circuits the heuristic re-resolution when the principal is known and still in the model (matching on ClrType only for non-shared types).
• 3 (invert identifying FK): As you described — when inverting an identifying FK between a non-derived and a derived type, the inverted FK now stays between the derived and non-derived type instead of collapsing onto the base. Added regression test Inverting_identifying_relationship_keeps_derived_dependent.

Validated against the full EFCore.Tests (6917) and EFCore.InMemory.FunctionalTests (27955) suites.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.