live queries: subscription-driven re-render from the browser peer, and @fluree/react

[aaj3f]

This is the third and final PR of the wasm program, and the one with a product behind it. #1714 made the engine run in a browser; #1715 made it a peer that reads a real server. This makes it live: a commit on the server re-renders exactly the affected React component, in a browser tab, with no polling code anywhere in the application.

The demo is the argument. Two tabs on one ledger, a vote cast in tab B, and in the untouched tab A only the changed row re-renders — its counter goes 1×→2× while both sibling rows sit at 1×, and a second panel querying the same ledger re-runs and does not re-render at all, because its answer did not change. fluree-react/demo/WALKTHROUGH.md is a five-step script for running exactly that, written so someone can present it cold.

What's in it, bottom to top

Engine (fluree-db-api). Head-change catch-up now prefetches the novelty translation leaves it is about to need, so a subscription's re-query after a commit is a resident hit rather than a fetch round. The incremental catch-up ceiling is raised on wasm (5 → 64 commits) with a measured rationale — the parent-chain walk is one sequential fetch per commit, so at browser RTTs ~64 is roughly where catch-up stops beating a full reload — and the beyond-ceiling reload path was verified to still emit the "queryable at t" signal, so a sleeping tab that wakes far behind still fires exactly one cycle.

Live-query driver (fluree-db-browser). A subscription registry and an advance-cycle: on a head change, take ONE frozen snapshot, hold ONE cycle-level query guard, re-run every subscription against that single view, hash each formatted result (xxh3) as a change gate, and emit ONE batch outcome — {ledger, t, changed, unchanged, errored}. Unchanged subscriptions ship zero payload. Mid-cycle head events fold into exactly one follow-up cycle at the latest head, never a queue. Sibling components therefore cannot disagree about which commit they are showing, which is the invariant everything above depends on. The v2 invalidation filter has a seam here (affected(&flakes) -> bool, default true, never consulted for a subscription that has not yet produced a result) but v1 deliberately re-runs everything and diffs — correct by construction, and the diff gate is what keeps it cheap.

Shell (fluree-db-wasm + @fluree/db-wasm). Peer mode: connect(url, {getToken, …}), an unsolicited worker→main event channel (versioned), and subscribe/unsubscribe verbs that surface each advance-cycle as one batched cycleOutcome event with payloads transferred rather than cloned. Credentials never ride the init message — the worker asks for a token over the event channel and the main thread answers — which matters because a crash recycle replays init. Live subscriptions work in playground mode too, driven after local commits, so the no-server demo is live as well.

@fluree/react — a new top-level npm package, not a cargo workspace member, with its own path-gated CI job. A framework-agnostic core (client → query cache → handles → observers) with a ~100-line React adapter on useSyncExternalStore; React context injects the client only, never data. Two transports behind one hooks API: remote (HTTP queries, SSE-triggered cycles — no wasm anywhere, server-renderable) and peer (the in-browser engine). connect is injected rather than imported, so the package has zero dependency on @fluree/db-wasm and remote mode bundles without wasm. Unchanged rows keep object identity across an advance, which is what makes React.memo work down the tree.

Decisions worth scrutiny

• The cycle is the unit, not the subscription. Per-subscription callbacks would be simpler, but they de-batch the cycle — which destroys version coherence — and drop unchanged, which the cache needs for error→ready recovery. Hence onCycle/onEngineState as shell API additions.
• v1 re-runs every subscription per cycle. Fine on the peer (local CPU) and the diff gate means an unchanged result costs zero renders and zero payload. Not fine in remote mode, where it is N HTTP round-trips per commit — and there is no multi-query endpoint to fold them into (verified). Documented as a known cost with a bounded fan-out and request cancellation, not hidden.
• Two refusals rather than silent wrong answers. In peer mode opts.at (historical views) and non-language-matched opts.format surface as typed unsupported errors, because the engine has no such path and quietly serving something else would be worse.
• Structural sharing is reconstructed main-thread side, since postMessage clones. The worker's xxh3 gate decides whether anything changed; identity is preserved against the previous result after the boundary.

Two wasm cache guards that look redundant and are not

Worth stating because the natural review instinct is to collapse them. ledger_manager::temp_cache_dir returns a synthetic path on wasm instead of calling env::temp_dir(), which prevents a panic — temp_dir() aborts with "no filesystem on this platform". fluree_db_core::disk_cache::ensure_cache_dir makes create_dir_all on that path a no-op on wasm, which prevents an error that would otherwise abort the index load before any CAS fetch is attempted. Different failure, different layer; removing either one reintroduces a distinct bug. Verified that no other create_dir_all sits on the wasm read path — the remainder are import and server-defaults paths, native-only.

Performance, stated honestly

Peer mode is not a speed-up on first paint, and the README says so in a section with that title. Measured: remote mode reaches first rendered data in 141 ms on loopback; a peer cold open is ~3.4 s. Profiling the peer cold open found something worth the team's attention: ~3.3 s of it is fixed overhead, invariant to data size — a 2-row ledger costs 3,318 ms and a 200-row ledger 3,547 ms — and the worker is 90% on-CPU throughout (3,538 ms busy vs 327 ms idle, with 23 ms of network). That number is bug-shaped rather than tuning-shaped, it is not addressable by any transport work, and finding its root cause is now the top perf item for the browser peer. It is localized to load_and_attach_binary_store, Fluree::db, and execute_formatted, but not root-caused; nobody should read this PR as claiming otherwise.

Choose peer mode for update latency and offline-capable local re-query, not time-to-first-paint. A warm re-query is 49–182 ms. One useful lower bound fell out of the hang investigation: with IndexedDB entirely out of the picture (a wedged database, so the peer runs fully cache-less) it serves in 252 ms, and two engines in two tabs serve in 252/262 ms — so the cache is not what the cold open is waiting on.

Native impact is unchanged from #1715's posture: the engine changes are cfg-gated or behind default-None trait methods, and @fluree/react is not in the cargo workspace, so no Rust job builds because of it.

What live runs found that the test suites could not

178 vitest tests, all mocked, all green — and running the thing in a real browser against a real server found six defects they were structurally incapable of seeing. Every one was silent:

• fetch held as an instance property and invoked as a method — every browser rejects that as an illegal invocation; Node does not check, and every test injected a fetch impl.
• A subscription under a bare ledger name never matching the server's canonical name:main, so head events were discarded as unwatched: stream open, nothing erroring, nothing updating.
• The reverse of the same mismatch inside the package, filing cycles under the engine's spelling so ledgerHead() read as unknown forever.
• The demo's own row mapping discarding the object identity the package had just preserved — everything still "worked", every row just re-rendered forever. A single .map() in userland silently defeats the entire point of the package, which is why it now leads both READMEs.
• Vite's dev server refusing to serve files outside the project root, surfacing as engine_crashed with an empty page console.
• GET /events?ledger= returning 400 for every value — shipped separately as fix(server): accept per-ledger SSE subscriptions on GET /events #1730, since it breaks any peer subscribed to explicit ledgers and has nothing to do with wasm.

The end-to-end gate that catches this class now runs in CI: it launches a real fluree-server, mints a scoped storage-proxy token, drives the shipped npm package in headless Chrome, and asserts rows — plus a cold, head-tracking-off phase in its own fresh profile. Its traffic assertions are the interesting part, and they are shape assertions rather than magic numbers: every recorded GET /storage/objects/{cid} succeeded (a partial failure fails the gate rather than degrading quietly), exactly one SSE stream, and zero requests to /query — that last one is what proves the engine computed locally instead of shipping the query to the server. A run records around three dozen CAS objects; that count is reported, not asserted, since it moves with the data.

Known blockers and open items

• Peer hang on an unopenable cache — fixed. The driver awaited the IndexedDB open before entering its job loop, so if that open never returned, no job was ever dispatched: no HTTP request, no error, and no timeout (the per-request timeouts live inside the job that never ran). The trigger turned out not to be "cold" at all — a wedged database whose open() fires no event whatsoever, not even blocked, which is durable per browser profile and is why fresh-profile testing never reproduced it. The driver no longer depends on the cache opening; a wedged or unavailable IndexedDB now degrades to cache-less operation, exactly as the module's doc comment always claimed. Verified before/after on the same wedged profile with the failing precondition re-probed during the passing run.
• Enqueued jobs had no deadline — closed. The configured request timeout is applied inside the job, so anything preventing dispatch hung forever with nothing to surface it. There is now an outer deadline that needs no new dependency: the timer is !Send because it holds JS handles, so it runs in its own spawn_local task and is observed over a channel — this module's founding trick, and deliberately not routed through the driver, since a deadline that depends on dispatch cannot detect dispatch failing. Native is byte-unchanged; the error names the URL and says "did not dispatch", so "never started" is distinguishable from "timed out". Two tests guard it: one holds the receiver without draining (a live-but-not-dispatching driver) and asserts the typed error, the other asserts a reply inside the deadline still wins so the guard cannot mask real behavior.
• Remote mode requires fix(server): accept per-ledger SSE subscriptions on GET /events #1730, which is not in any release. The README names the symptom so nobody debugs their own application first.
• Peer mode needs a token our own CLI cannot mint — fluree-events-token issues only fluree.events.*, while the storage proxy requires fluree.storage.*. A --storage-all flag would fix that and is not in this PR. Follow-up: events-token CLI: option to mint fluree.storage.* scopes for the browser peer #1773.
• The ~3.3 s cold-open floor, above. Follow-up: Browser peer cold-open floor (~3.3s): root-cause the on-CPU time #1774.

Pre-review remediation (before this leaves draft)

This PR went through a blind internal pre-review first — a reviewer with no context on the work, applying the repo's own rubric, checking the PR out like any colleague's. Verdict was request changes over 32 findings, and all 32 are now closed: fixed, or rebutted with mechanism. Highlights, because several are more interesting than the fixes:

The critical one falsified this PR's own headline claim. prime bypassed the coalescer while advance went through it, and nothing downstream ordered by watermark — so a slow prime landing after a fast advance pinned a component on pre-commit data and left its stored hash at the stale result, meaning a later commit restoring that result reported "unchanged" with no payload and the component never recovered. "Sibling components cannot disagree about which commit they're showing" was true within a cycle and false across two. Fixed structurally rather than patched: advance and prime are now one serialized path, so there is one concurrency regime per ledger, and Coalescer::begin returns an RAII lease that releases the slot on drop.

Two findings turned out worse than the review stated. A failed block fetch during result formatting was answering 400 err:system/FormatError — telling a caller its data was malformed on a condition a retry fixes; it is now a 503 err:storage/ReadFailure, with the same shape one frame over flagged rather than quietly left. And the events parser's all flag accepted only the literal strings true/1, so ?all=TRUE, ?all=yes and every typo silently meant false — a 200 SSE stream matching nothing, forever. That second fix ships in #1730, which owns that parser (see the note below).

A "never" timer that fired immediately. Five sites clamped a duration with u32::try_from(..).unwrap_or(u32::MAX); a setTimeout delay above i32::MAX overflows and fires at once, so the value meaning "effectively never" meant "now". Found while mutation-checking something else, when a deliberately-wedged open resolved instantly.

Two documentation claims were checked and could not be stood behind, and that matters here because this README's whole framing is separating claims by evidence: a coverage row claiming the remote suite proved per-subscription delivery ordering (the reviewer neutered the entire ticket mechanism and all tests still passed — the missing test has been added rather than the belt removed), and "thirty subscriptions do not fire thirty simultaneous requests", which was false at mount because the limiter only applied inside cycles. The demo also contradicted its own headline — App.tsx said "search this file for a timer, an interval; there are none" and contained a setInterval. Fixed the code, not the claim.

One finding was declined, with reasoning: a wasm-paths CI gate analogous to bench-paths. bench-compare measures a known crate set, but wasm-smoke runs the engine and its failures are runtime ones any engine crate can cause — so an honest gate would match nearly everything, and a narrow one is the same silent-skip trap as the react-sdk path-gate bug fixed in this PR. Reducing that job's feature set was the saving that doesn't trade correctness for it.

Test counts after remediation: fluree-db-browser 62, it_residency_retry 8, fluree-db-server lib 151, @fluree/react 200, headless-browser suites 11, plus the real-server peer gate passing end to end.

Overlap with #1730, deliberate

The two commits here touching fluree-db-server/src/routes/events.rs are byte-identical to #1730's first commit. That fix was extracted so it could land early and independently — it breaks any peer subscribed to explicit ledgers, which has nothing to do with wasm — and this stack needs it because the peer gate subscribes with ?ledger=. When #1730 merges, these two become patch-identical to main and drop on rebase; the ?all= fix lives only in #1730.

Named gaps, not absorbed

The shell index.ts surface is now covered by a vitest suite IN this PR (fluree-db-wasm/js/test/, wired into the react-sdk CI job): globalThis.Worker is stubbed with a message-recording double and connect({ workerUrl })/playground({ workerUrl }) drive the real Channel, toLiveCycle, recycle ladder and LiveRegistry with zero production changes. Seven tests pin the cycle-decode memo (one parse per payload, shared object identity), the fatal-re-init single-recycle guard, init-failure worker cleanup, the 30s init timeout, per-query timeoutMs passthrough on both query surfaces, and the setToken wire contract — each proven non-vacuous by mutating the committed guard it pins and watching it fail. The peer.rs drain is covered by the peer gate plus the coalescer tests in fluree-db-browser::live. On tokens: review found that BrowserPeer::set_token existed (tested) but nothing above it called it, and two docs contradicted each other about it. It is now wired through end to end — Peer.setToken(token) → a setToken op → a peer-only worker dispatch → the shared TokenCell — so a long-lived tab can refresh its bearer proactively with no teardown; getToken remains the pull at connect/crash-recycle, and both docs now agree.

External adversarial-review remediation (2026-09) + caught up to main

Since the pre-review, this stack was rebased onto current main (49 commits; semantically verified at each level, not just textually) and put through a second, independent adversarial review of the surface the internal pre-review and the human reviewer had NOT covered — the wasm read-path, the two new browser crates, and this PR's Rust + TypeScript. Every agreed finding is fixed in-tree, each verified by execution (mutation-checked where a test pins behavior), not by description:

• Correctness. The change-gate hash is now committed only when a cycle is actually delivered (an auto-prime racing listener registration previously wedged a subscription at "unchanged, no payload"); onLedgerHead's detach is idempotent (a stale cleanup no longer evicts a re-subscribed component's head listener); a peer cycle spanning two spellings of one ledger is delivered under each spelling; a query first observed after close() returns a typed error instead of loading forever.
• Performance (the maintainers' first-ranked axis). The SSE drain now spawns each advance so the coalescer folds a head-change burst into one cycle instead of running one full re-query per event; each live cycle is decoded once, not once per listener; and the residency read-ahead is bounded so a LIMIT-shaped scan no longer fetches the whole predicate run (with an airtight retry-termination gate, in wasm32 groundwork: the engine stack compiles and runs on wasm32-unknown-unknown, native untouched #1714).
• Security / robustness. A persistent-cache hit is re-verified against its CID before the engine trusts it (IndexedDB was the one unverified admission path); the bearer token is redacted in IoJob's Debug; the SSE connect is bounded (a hung server no longer silently kills head-tracking); and an oversized/flooding response is rejected/backpressured before it can trap the wasm instance.
• CI. Three host-target clippy errors that would have gone red on merge are fixed.

Deferred, deliberately and tracked (not silent backlog): the per-block CORS preflight is its own follow-up PR — #1772, a batch object endpoint (a maintainer decision, since it is a cold-profile-only perf item, not correctness); a fluree-events-token --storage-all scope flag — #1773 (a separate server-CLI change the peer needs to self-serve a storage token); the ~3.3 s cold-open floor root-cause — #1774; and the dataset-residency formatting seam — #1775 (the hydration branch now refuses typed on a residency-backed target instead of dying on an unrecoverable miss; the real fix is hoisting the retry loop with per-graph store routing).

[bplatz]

Approving — the design holds up. One snapshot + one nested cycle guard + a hash gate on formatted bytes is the right shape, the RAII lease means cancellation can't wedge a ledger, the IndexedDB CID re-verification (with cache_rejections and its poison-and-heal test) closes a real hole, and structuralShare's __proto__ handling on both the read and the write side is more careful than most implementations. The timer_millis clamp is a good catch, pinned by mechanism rather than symptom.

Please look at the inline points before merging. The one I'd actually act on is set_token: it ships with a test and has no caller anywhere in the stack, and two doc comments in this PR contradict each other about whether it exists.

Verified locally: fluree-db-browser 66 tests pass, @fluree/react 205 pass under tsc + vitest + build, cargo fmt --all --check clean. The wasm32 clippy gate I could not cross-build here.

Two housekeeping items: the PR has no labels, so .github/release.yml files it under "Other Changes"; and none of the four named deferrals (CORS batch endpoint, --storage-all, shell vitest, the ~3.3s cold-open floor) carry a Follow-up: #N. fluree-db-wasm/js/src/index.ts is ~1100 lines with no test runner — the PR shows it's testable with zero production changes, so I'd rather see that suite here than deferred.

[bplatz]

BrowserPeer::set_token does exist — it's added in this PR with a passing test (connect.rs:279). But nothing calls it: no set_token/setToken in fluree-db-wasm/src, js/src, or fluree-react/src, and getToken is only pulled at connect/reconnect.

So a peer tab whose token expires 401s on every block fetch with no recovery — nothing in PeerTransport triggers a close+connect on that. bridge.rs:22 also claims "the shell's auth flow refreshes the bearer mid-session", which no shell does.

Either wire it through (one Peer method + a setToken op) or drop the capability. Either way both comments need fixing.

[aaj3f]

Wired through, the shape you suggested: Peer::setToken (wasm export) → a setToken protocol op → a requirePeer dispatch in the worker (playground answers with the same typed unsupported the transact ops use in peer mode) → Peer.setToken(token) on the JS surface. (77c469b)
You were right that both comments were wrong — peer.rs claimed no re-auth hook exists while bridge.rs claimed the shell already refreshes. Both now say the same true thing: proactive refresh needs no teardown, and getToken stays the pull at connect/crash-recycle — the two compose (refresh before expiry via setToken; a 401 that lands anyway still surfaces typed and recovers through recycle/reconnect with a fresh getToken pull).
The Rust half was already pinned by set_token_refreshes_the_bearer_without_teardown; a shell-side protocol test rides the new vitest suite in this PR.

[bplatz]

A comment is the only thing between a multi-ledger peer and an unrecoverable formatting miss here. Worth hoisting the loop into a helper both paths call, or returning a typed refusal on a residency target — and a tracked follow-up rather than prose.

[aaj3f]

Took the typed-refusal option and filed the tracked follow-up you asked for: #1775. The prose guard is now a live assertion — if ANY graph in the dataset is residency-backed, the hydration branch returns a typed error naming the issue instead of dying on an unrecoverable mid-hydration miss. Fires never today (the browser peer is single-ledger), which is exactly the invariant the old comment narrated. (098ad55)
I went refusal-over-hoist deliberately: wrapping this branch in the existing loop would give FALSE recovery for a multi-ledger dataset — misses can come from a secondary graph's store and the loop only fetches against one store, so it would spin to a non-progress failure rather than recover. The real fix (hoist into a shared helper with per-graph store routing) is what #1775 tracks.

[bplatz]

Each round re-runs the body against the same tracker. Formatting is pure w.r.t. resident state but not w.r.t. the fuel counter, so a query near budget can fail FuelExceeded purely for having taken N rounds. Same shape as the execution loop, so not a regression — but on a peer, misses are the normal path, so it's likelier to bite. Snapshot/restore per round, or state the trade.

[aaj3f]

Fixed — snapshot/restore, your first option. The loop snapshots the counter once (Tracker::current_micro_fuel) and rolls back before each retry via a new Tracker::restore_micro_fuel, so N rounds charge like one and the successful round's charge stands. (098ad55)
It's sound in this frame specifically because execution has already finished — formatting is the tracker's sole fuel writer, which is now a documented caller invariant on the API (the rollback would erase a concurrent consume_fuel, which is also why I left the execution loop exactly as you read it: its rounds run concurrent consumers, and you're right that it's not a regression there).
Two unit tests pin the API (rollback semantics; inert when fuel tracking is off).

[bplatz]

Clearing running is the point; clearing pending isn't. A head change that folded into a cycle which then got cancelled is dropped entirely, and nothing re-runs it until the next commit. "The next signal opens a fresh cycle anyway" only holds if there is a next signal.

The lease exists so safety doesn't rest on caller behavior — leaving pending set costs nothing and makes the code match the doc.

[aaj3f]

Fixed — abandon() now clears only running. Tracing the consumer made your point sharper than "costs nothing": pending is only ever consumed by the NEXT cycle's finish(), which then forces one more FULL cycle — and that upgrade is load-bearing when the next cycle is a prime() (deliberately solo, one subscription). Dropping pending on abandon meant a prime racing a cancelled cycle served only itself and stranded every sibling subscription on stale data until some unrelated commit arrived. (4d5ddeb)
Two new tests pin it (Coalescer-level: a dropped lease still owes a follow-up; public-API level: an abandoned cycle's folded commit reaches an earlier subscription via the follow-up a later prime forces), both mutation-verified; monotone emission order is untouched — the abandoned cycle never emitted.

[bplatz]

Only guards a declared Content-Length. A chunked response with no header skips the pre-check and is fully materialized into linear memory — the exact thing this prevents. Fine against our own proxy; not a defense against the "hostile or broken server" the comment invokes. Narrow the claim or cap incrementally.

[aaj3f]

Implemented the incremental cap rather than narrowing the claim. Body reads now stream through a ReadableStreamDefaultReader with a running total gated per chunk (config::body_cap_step — one saturating add + one compare, same shape and cfg-gating as declared_length_over_cap, natively unit-tested including the two-chunks-under-declare-nothing case); on overflow it aborts the controller + cancels the reader and returns typed. The declared-length fast-reject stays. Two details worth noting: the whole drain races ONE timeout (a trickle of small chunks can't reset the deadline per read), and each chunk is copied out of JS memory exactly once — which also retires the 2x materialization array_buffer() had on this path. (4d5ddeb)
The streaming loop itself is wasm-only; it runs green in the headless-Chrome suite (fetch round-trip tests), and the threshold logic is pinned natively.

[bplatz]

storeFor/observe/snapshotFor all short-circuit on closed, but public handleFor doesn't — a call after close() inserts into byKey/bySubId and skips armJanitor(), so it's never collected. One-line guard.

[aaj3f]

Fixed, with one refinement to the framing: the branch was already half-defended — liveHandleFor guarded armJanitor() on closed but still unconditionally inserted the fresh handle into byKey/bySubId, which is the actual leak (no janitor AND no possible observer, since observe short-circuits on closed, so collect() can never fire). It now returns a standalone untracked handle when closed instead of touching the maps. (846a265)
Kept handleFor public rather than privatizing: the whitebox cache tests drive it directly, and the guard is the smaller surface change. New regression test asserts a post-close handleFor call caches nothing (two calls for a fresh key return distinct handles); mutation-verified (reverting the guard fails it).

[bplatz]

byEngineId is only populated after this await, while the engine auto-primes the moment it registers (wasm/src/live.rs:55). It works because the subscribe reply and the cycle event are separate postMessages and the reply's microtasks drain first.

If that ever inverts, applyCycle drops the payload while Rust has already committed the change-gate hash — and the next cycle reports unchanged on a handle with hasResult === false, i.e. the transport-contract error path. The Rust side guards the analogous race explicitly (deliverable in run_serialized); this one has no guard, comment, or test.

[aaj3f]

Agreed the microtask-ordering assumption deserved a real guard, not prose — it now mirrors the Rust side's deliverable gate. A pendingRegistrations counter brackets register()'s await (try/finally), and applyCycle stashes an entry it cannot place — keyed by raw engine id — only while a registration is in flight; when the subscribe reply lands, the stash is replayed as that subscription's own CycleUpdate (watermark included). The stash clears whenever the pending count returns to zero and on crash-recycle (a fresh worker can reissue a dead worker's ids — same hazard the existing byEngineId.clear() there guards). Normal delivered path pays one counter check. (846a265)
New test holds the subscribe reply open, emits the auto-prime cycle first, and asserts it is delivered (not dropped) once the reply resolves; mutation-verified (no-oping the stash fails it).

[aaj3f]

All seven inline points are addressed in code (each has a thread reply with the commit), plus the two housekeeping items: both PRs now carry the enhancement label for release.yml, and the four named deferrals have tracked follow-ups — CORS batch endpoint #1772, --storage-all #1773, the ~3.3s cold-open floor #1774, and the dataset-residency formatting seam #1775.
On the shell suite: agreed, and it's in this PR now rather than deferred — a vitest harness over fluree-db-wasm/js (worker stubbed via connect({workerUrl}), zero production changes) covering the decode-once memo, the crash-recycle re-init ladder, init failure/timeout cleanup, and the setToken/timeoutMs protocol surface, wired into the react-sdk CI job. (a07f48b + aff437c: 7 tests, each mutation-verified against the committed guard it pins)
Also from re-running the browser gates while closing these out: the wasm-smoke job unmasked a main-inherited runtime trap — the commit cancellation-shield's bare tokio::spawn (from the #1662-adjacent shield work) panics on wasm32, which took out every playground transact in a real browser. Fixed at the same seam pattern as spawn_detached (wasm_compat::spawn_shielded: native path unchanged, wasm runs the window on the event loop with the result over a oneshot, spawn stays eager so the shield property holds). Proven by the previously-failing suite: 6/6 in headless Chrome. (5b1a5d9 on the base PR, #1715)