Fix FK dependency ordering for owned entities with external FK references (WIP)

[Copilot]

Addresses issue #36059 where FK dependency ordering is incorrect when replacing an owned entity that has a foreign key to a non-owner entity, causing FK constraint violations during SaveChanges.

Problem

When replacing an owned entity that has a foreign key to a non-owner entity, SaveChanges generates commands in incorrect order, causing FK constraint violations. The DELETE of old referenced data executes before the UPDATE that switches the reference.

Example scenario from issue #36059:

• Document owns File (table-split)
• File has FK to Content
• When replacing File: Current order is DELETE Content1, UPDATE Document, INSERT Content2
• Expected order: INSERT Content2, UPDATE Document, DELETE Content1

Current Status

⚠️ Work in Progress - Investigation ongoing

CommandBatchPreparerTest.cs

• ✅ Added test case using actual owned entities (FileEntity owned by DocumentEntity with FK to ContentEntity)
• ✅ Test properly reproduces issue FK dependency ordering wrong when replacing an inline owned entity #36059 and fails without a fix
• ✅ Test verifies correct command order: INSERT new content → UPDATE owner → DELETE old content

CommandBatchPreparer.cs

• ⚠️ Fix development in progress
• Root cause identified: Table-level FK processing skips owned entity FKs when IsModified returns false
• The original fix from PR Fix FK dependency ordering when replacing owned entities with foreign key references #36769 (targeting release/10.0) does not work for actual owned entities with table-splitting

Investigation Findings

The issue occurs because:

1. For owned entities with table-splitting, FK properties are shadow properties on the owner
2. When owned entities are replaced, change tracking may not mark FK properties as modified
3. IsModified(foreignKey.Columns, command) returns false at line 768, skipping dependency creation
4. Without the dependency, commands are ordered incorrectly

A new fix is being developed that handles FK dependencies for owned entities even when change tracking doesn't detect modifications.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[AndriySvyryd]

@copilot This test passes even without the fix. Modify it so it fails without the fix

[Copilot]

Fixed in commit 7fd2d9c. The test now uses actual owned entities (FileEntity owned by DocumentEntity with an FK to ContentEntity) and properly fails without the fix. However, I discovered that the fix from PR #36769 doesn't make the test pass either, suggesting there may be an issue with the original fix or additional work needed to make it work correctly with the owned entity scenario.

[AndriySvyryd]

@copilot Ok, then develop a different fix. Note that the original issue was reported at #36059

[AndriySvyryd]

@copilot Continue