Optimistic store truth-flight should own its transaction rather than rely on ambient adoption #3146

Follow-up (2) from #3141 / #3145.

The generator store's authoritative flight (initial run, per-yield landings, post-await draft writes) has no transaction of its own: each landing's settle path asks resolveTransition and otherwise joins whatever is ambient (initTransition(null)). #3145 closed the window in which a stranger transaction could be ambient at landing time, but the underlying shape remains: the flight's relationship to transactions is circumstantial (whatever is ambient or stamped at each landing) rather than declared.

Giving the truth-flight a dedicated transaction would make the semantics explicit:

• every landing of one flight belongs to the same, flight-owned transaction — entanglement with other work happens only through the documented graph-driven channels (A15), never through timing;
• the 2.0.0-beta.26 | optimistic store unexpected pending state for store or dependency, while having an optimistic override #2951 contract (a bare optimistic write during the store's own truth-flight rides the truth) gets a first-class anchor — today it routes through fam.node._transition, which is whatever last stamped the firewall, and 2.0.0-rc.4 | optimistic store, read in an effect, changes the visible rendering. and has inconsistent value when logged and when rendered. #3141 showed that stamp can be a stranger's;
• transitionBlocked's store-half (hold while flight pending + overrides live) stops needing to reconstruct ownership from _optimisticStores membership.

Needs design attention on: per-yield commit timing (each yield should still reveal on arrival per A18(1) — one flight-transaction must not batch all yields to flight end), and interaction with refresh()-initiated flights which already carry the refresh transaction.