Stale @refs silently resolve to the wrong node after the session tree changes

[thymikee]

Observed while dogfooding Bluesky (2026-07-04, main + #1075 fixes):

1. snapshot -i → @e37 = the post body text ("Pretty sure this is the first award…", y≈245).
2. One tap "label=..." in between (its resolution capture refreshed the session snapshot; the feed also loaded new content).
3. get text @e37 → success, returning "2.7K likes" from a like-count StaticText at y≈847 — a completely different node, no warning.

Same session, second occurrence: press @e69 (was the Search tab at y=793) failed with offscreen_ref because e69 now pointed at a node at y=1108 — the guard caught it only by luck of geometry.

Refs are positional indexes into the latest session tree, and any selector-based command silently reshuffles them. STALE_REF handling exists for refs that vanish, but a ref that still exists pointing at a different element is a silent wrong answer — for an agent this is worse than an error, since it corrupts downstream reasoning (reading the wrong text, pressing the wrong control).

Expectation (design discussion needed): the session could stamp each snapshot with a generation counter and remember which generation served the refs the client last saw; commands taking @ref args could then either (a) warn in the response when the tree was replaced since that generation, or (b) compare the resolved node's label against the recorded refLabel for that ref and refuse/warn on mismatch (the replay fallbackLabel machinery already does something similar). Zero-cost paths should stay zero-cost; even a response-level refsMayBeStale: true marker after a tree-refresh would let agents re-snapshot instead of trusting garbage.

[thymikee]

PR #1093 (the coarse boolean warning) is approved and pending merge; it deliberately keeps this issue's deeper hole open (a fresh find ref blesses older refs — one boolean cannot carry per-ref provenance). The agreed follow-up is now in progress: versioned refs (@e37~s12 accepted as INPUT; tree output stays plain so snapshots pay zero extra tokens; refsGeneration rides ref-issuing responses once; the MCP layer auto-pins plain refs transparently for exact provenance at zero prompt cost; warn-only for one release, tightening after). This issue stays open to track that follow-up PR.

[thymikee]

Enforcement decision point (on the record per the #1096 merge condition): after one release of warn-only pins, review measured stale-pin warn rates from real MCP sessions and decide MCP-only stale-pin enforcement (refuse before dispatch instead of warn). Known consideration for that review: selector interactions bump the generation without reissuing refs, so mixed selector/ref loops produce generation-stale-but-node-correct pins — if warn rates show that pattern dominating, enforcement needs finer granularity (e.g. a cheap node-identity check alongside the generation) before flipping. The --settle work (#1101) reduces exposure structurally by making fresh refs ambient in settle flows; enforcement covers everything else.