Support separate navigation query and update mappings, including read-only navigations

Start with the parent tracker #20339 and the related issues #20337 and #33171 to understand how this work is divided. The issue calls for design across navigation metadata, query translation and loading, change tracking, model finalization, and compiled models; no specific files or tests are named. Done means defining and implementing query-only and separate query/update navigation mappings with clear mutation behavior and lifecycle support.

A navigation used to query related entities does not always represent an association that can be changed by assigning the reference or adding/removing collection elements. Its query mapping may also differ from the target entity type's normal query source or from the relationship used to persist association changes.

Similarly, a model may expose both a read-only relationship and a derived, writable navigation to the same target entity type. These navigations need different query semantics without inventing additional persistence relationships.

Current ordinary navigation metadata is tied to a foreign key. Navigation mutation and relationship fixup operate on that relationship. This does not provide an independent contract for a query-only association.

Existing support and workarounds

EF already supports some separation at the entity-type level: an entity can be queried through a view and updated through a table. This issue should preserve and build on that behavior, not reintroduce it as a new feature.

However, entity-type table/view mapping does not independently describe how a particular navigation is queried or whether mutations to its association can be persisted.

Neither a getter-only property nor IReadOnlyCollection<T> establishes this semantic distinction. EF can populate navigations through backing fields and collection accessors, and CLR API shape alone does not specify persistence behavior. Likewise, AsNoTracking controls tracking of query results rather than declaring an association read-only.

Explicit LINQ queries/projections can compute derived associations today, but do not provide a reusable mapped navigation with ordinary loading semantics.

Describe the solution you'd like

Separate the metadata and behavior used to query a navigation from the relationship/update mapping used to persist changes to its association.

Allow an explicitly configured query-only navigation with no association update mapping. Allow an independently configured update mapping where a persistable relationship exists. The exact configuration API and supported combinations need design.

"Read-only navigation" should mean that EF does not infer or persist association changes from that navigation. It should not mean that the returned entity instances are necessarily read-only, keyless, or untracked.

Design considerations

• Query mapping: Describe navigation query semantics independently of the target entity type's default mapping and of any writable relationship. Query translation and loading must consistently honor that mapping.
• Association mutation: Define what happens when a read-only reference is assigned or a read-only collection is changed, including changes made through backing fields or the change-tracking API. Unsupported attempts to persist association changes should have explicit diagnostics rather than silently succeeding or changing another relationship.
• Materialization and fixup: EF must still be able to populate query-only navigations. Distinguish internal materialization/fixup from application mutation. Define whether and how already-tracked entities participate; fixup must not populate a derived navigation using only the target's ordinary foreign-key relationship.
• Entity updates: Returned keyed entities can retain their normal update mapping. Updating their scalar properties should not require the navigation association itself to be writable.
• Relationship side effects: Query-only associations must not introduce synthetic foreign keys, join tables, cascade deletes, orphan deletion, or ownership semantics merely to represent their query behavior.
• Consistency: Define loaded-state and reload behavior when source or target properties affecting membership change. Do not imply that arbitrary database-defined associations can always be maintained automatically in memory.
• Writable mappings: When both query and update mappings exist, define how reference/collection changes affect the writable relationship, including inverse navigations, and how discrepancies between queried membership and writable membership are handled.
• Metadata lifecycle: Preserve configuration through conventions, model finalization, runtime/compiled models and snapshots where applicable. Query-only metadata should not produce spurious schema operations.

Scope and related work

• #20339 is the parent tracker for flexible navigation mapping.
• #20337 tracks a specific consumer: implicit many-to-many associations without a join table.
• #33171 tracks custom joins/query mappings for read-only navigations. This issue supplies the query/update separation and mutability contract, rather than the syntax or translation of arbitrary joins.
• Mapping navigations to database functions is another consumer of this separation and should have its own focused tracker under #4319/#20339.
• General immutability of entity instances, new query-source forms, and automatic in-memory reevaluation of arbitrary queries are not required by this issue.