fix(web): an async message listener does not serialize, and a watchdog must not overwrite a real error

Three findings from the review-only PR #13, which put 28 already-merged
commits in front of a second reader, plus two comments that had gone false.

worker.js — `self.onmessage` was `async` and awaited `handle()`, which awaits
`server.flush()`. An async listener does NOT serialize: the event loop may
start the next `message` while an earlier one is suspended at an await, so two
`on_message`/`flush` pairs interleave and a later frame's replies can be posted
before an earlier frame's. That breaks the one rule the file names first — a
`GridUpdate::Cells` that overtakes its labels is DROPPED by the client's fold,
not replayed (gotcha 33) — and the pre-start `pending` drain had the same race
twice over, since `server` was assigned before the loop that drained it, so a
message arriving mid-drain overtook the frames it was queued behind. Every
frame is now chained onto one tail promise, which also makes "arrived before
start() finished" an ordinary case of the same rule instead of a second path.

app.js — the handshake watchdog fires 8s after the handshake and writes "the
peer did not answer". A peer that failed LOUDLY has already said something more
precise (worker `error`, `messageerror`, socket `error`), and the watchdog then
overwrote it with the vaguer guess. Those three paths now disarm it:
`setShellFailure` clears the timer rather than merely pre-empting it. The
watchdog is for silence only, which is what it was always for.

README — the "In the browser" section still said the deployed page needs a
server and that the in-page worker "is not built yet". Both landed in the same
unreviewed batch (improvise-9x6, improvise-djm), so the README described the
published site as a client with nowhere to connect while index.html described
it correctly. Rewritten, and it now states the caveat the commits state: no
line of that JavaScript has ever run.

Two comments that had gone false with it, and for the same reason — a follow-up
commit updated one copy and not the others. `web/app.js`'s keyboard note said
key resolution was "text entry, and nothing else" and that upstream keys would
work "until improvise-bpq2 lands"; bpq2 landed, moved the grid, panel and tile
cursors to the client, and settled that the host must not know the keymap.
`Host::handle`'s `ClientFrame::Key` arm said the same thing; 43422d4 corrected
the worker's copy of that argument and missed this one.

NOT VERIFIED, and it cannot be here: there is no browser and no headless DOM in
this environment, so neither JavaScript change has been executed. Both are
argued rather than tested, which is why each carries its argument in the file.
`node --check` passes on both, the wasm bundles build, and the Rust gates are
unchanged: 1172 passing / 0 failed, clippy clean, fmt clean, actionlint clean,
wasm32 clean for all seven bundle crates.

Declined from the same review, with the reason on the thread: `Host::commands`
can apply a batch's earlier commands before rejecting a later one. The finding
is correct, the hole is real, and it is already stated on `ClientFrame::Commands`
and in `Host::commands` — closing it means the basis check moving from the
command to the batch, which is a design change with ADR 001 consequences and
not a patch to land beside three small ones.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EoW5BB87ZZdm96SvBTWawH

README.md

@@ -183,27 +183,38 @@ and published from `main` by the `pages-build` / `pages-deploy` jobs in
 `.github/workflows/ci.yml`. A deploy only happens after `cargo test` and the
 wasm32 check have passed.
 
-**It needs a server, and a static host is not one.** The page is a thin client:
-it holds no model, and every question about a cell — its text, whether it may
-be typed into — is answered by a server and arrives already decided. So the
-published page paints an empty grid until it is pointed at one:
+**It needs no server.** The page is still a thin client — it holds no model,
+and every question about a cell, its text and whether it may be typed into, is
+answered by a server and arrives already decided — but the server it talks to
+is an in-page Web Worker hosting the whole `App` over the browser's private
+storage (OPFS). It is seeded on first load from `web/demo.improv`, so a visitor
+lands on a document, and edits persist across a reload without leaving the
+machine. `?doc=` and `?seed=` name another document and the file it is first
+seeded from.
+
+To run the same page locally:
+
+```sh
+./web/build.sh                              # wasm-pack -> web/{pkg,worker-pkg}
+python3 -m http.server 8080 --directory web
+```
+
+To open a document hosted by a separate process instead — which is how a
+document open in the TUI is shared — start the websocket server and pass
+`?ws=`:
 
 ```sh
 cargo run -p improvise-ws-server -- examples/demo.improv --port 8787
 ```
 
-then open the page with `?ws=ws://127.0.0.1:8787`. Over https a `ws://`
-address is blocked as mixed content, so for now a local server is most easily
-paired with a local page:
+then reload with `?ws=ws://127.0.0.1:8787`. From an https origin a `ws://`
+address is blocked as mixed content, so that pairing is most easily done with
+the local page above.
 
-```sh
-./web/build.sh                              # wasm-pack -> web/pkg (gitignored)
-python3 -m http.server 8080 --directory web
-```
-
-Running with no separate process is the in-page worker, improvise-9x6, which
-is not built yet. Until it lands, what is deployed is the delivery pipeline,
-not a working demo.
+Caveat worth stating plainly: **no line of the browser JavaScript has ever
+run.** There is no browser and no headless DOM in the development environment,
+so `web/app.js`, `web/worker.js` and the OPFS backend are compile-checked,
+syntax-checked and read, never executed.
 
 ## What's interesting about the architecture