Fix unanchored optional/container child on same-id replace; expose modelID

[mansbernhardt]

Summary

Investigating a field report (a SwiftUI @ObservedModel view stuck at a model's birth state, no observation, never recovering — for a @Model with an explicit, reusable Identifiable id) surfaced one genuine framework bug plus some related API/diagnostic/doc gaps.

Fixed — optional/container child left unanchored on same-id replace

For a @Model with an explicit, reusable id, replacing an optional @Model child (var child: M?) — or any non-collection ModelContainer-typed property — with a fresh instance sharing the existing child's id left the new child unanchored:

• The ModelContainer write path had a fast path if containerIsSame(newValue, container) { container = newValue; return }. When the structure looked unchanged by .id, it stored the assigned value raw and skipped updateContext.
• That is correct only when the assigned value is the already-anchored live child. For a fresh instance reusing a domain id, it stored a pre-anchor value with no context — the child dropped out of the hierarchy: no observation, no tasks, no onActivate, reads returned its detached state. A view bound to it rendered birth state and never updated.

Fix: remove the fast path so the write always reconciles, reusing the existing child's context (continuity — matching the [Model] collection write path). Genuine no-op write-backs stay cheap via the per-element findOrTrackChild fast path. Only same-id replacement was affected; different-id and nil→value already anchored correctly.

Added

• public var Model.modelID: ModelID — the stable, per-instance identity, distinct from the (possibly domain-valued) Identifiable id. The reliable way to tell whether two model values refer to the same live instance. (Moved from the internal accessor; identical to id for models without an explicit id.)
• DEBUG duplicate-id diagnostic — assigning a model collection with two distinct instances sharing an id now reportIssues (mirroring SwiftUI ForEach). Keyed by modelID, so legitimate sharing (the same instance appearing more than once) does not warn.

Docs / tests

• Corrected the misleading "globally-unique ModelID / UUIDs" registry-key comments to describe the real same-.id stable-identity continuity contract.
• Added ExplicitIdReplacementTests characterizing behavior across single / optional / collection child shapes.

A known semantic difference (intentionally not changed here)

Same-id replacement now behaves like this:

var child: M	var child: M?	var items: [M]
replace (new state)	continuity (this PR)	continuity

The single-child path still replaces while collection/optional continue. Unifying on "replace everywhere" is not viable — it breaks ActivateTests.testChildrenCaseActivation, which depends on a fresh same-id element continuing the existing child. Unifying on "continuity everywhere" (bring single-child into line) is plausible but is a behavior change to the common model.child = X assignment and deserves its own PR/decision. Left as a follow-up.

Validation

Full suite green on both serial and parallel (781 tests; only the documented known-issue flakes). Release build clean.

🤖 Generated with Claude Code