ci(pages): build the wasm bundle and publish web/ to GitHub Pages

improvise-d31's finished artifact depends on improvise-9x6 (the worker-hosted
server) through improvise-djm. The *pipeline* does not, and building it now is
what stops the delivery half from being a mystery when the worker lands: the
swap from websocket transport to worker transport then changes what is
bundled, not how it is built and shipped.

Two jobs in ci.yml rather than a second workflow. `pages-build` runs on every
push and pull request, so a change that breaks `web/build.sh` or the bundle
fails on the PR that made it. `pages-deploy` runs only on a push to main and
`needs: [test, wasm, pages-build]`, so nothing that failed `cargo test` or the
existing wasm32 gate can reach the published site — the deploy depends on
those checks instead of repeating them.

Deliberately not path-filtered. The bundle is improvise-wasm-client plus
improvise-protocol, improvise-core and improvise-formula, so a filter meaning
"skip when the bundle cannot have changed" would have to name most of the
workspace, and getting it wrong leaves a stale site with nothing saying so.

wasm-pack is a pinned release tarball, v0.15.0 — the version `nix develop`
now supplies — so the local run that produced 346 KB of wasm (120 KB gzipped)
is evidence about the CI run. The devShell was missing wasm-pack entirely:
the `wasm` job only runs `cargo check`, which does not need it, so nothing had
ever required the one tool that turns a passing check into a loadable page.

What this cannot do yet, said on the page itself rather than routed around:
web/app.js is a thin client that holds no model, so a copy served from a
static host paints an empty grid until it is pointed at an improvise-ws-server
with ?ws=. The notice is static HTML, not something app.js decides, because it
is true on every load and a page that cannot reach a server cannot be trusted
to explain why. README says the same and names the deployed URL.

Verified: cargo test --workspace 1134 passed / 0 failed, clippy clean, fmt
clean, actionlint clean, ./web/build.sh succeeds and the assemble step
produces a 388 KB site whose every reference resolves inside it. NOT verified:
the workflow has never run — GitHub Pages is not enabled on the repository
(GET /repos/fiddlerwoaroof/improvise/pages is 404), which is improvise-3gy.
The deploy job asks configure-pages to enable it; if the token may not, that
step is where the run fails and the fix is the repository setting.

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

README.md

@@ -176,6 +176,35 @@ improvise cmd 'add-cat Region' 'add-item Region East' -f model.improv
 improvise script setup.txt -f model.improv
 ```
 
+## In the browser
+
+The browser page is at **<https://fiddlerwoaroof.github.io/improvise/>**, built
+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:
+
+```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:
+
+```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.
+
 ## What's interesting about the architecture
 
 All user actions flow through a two-phase command/effect pipeline. Commands