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

web/index.html

@@ -34,6 +34,32 @@
       <span id="status" role="status"></span>
     </header>
 
+    <!--
+      This page is the *client* half and nothing else. It holds no model: what
+      a cell is, what it says and whether it may be typed into is decided by a
+      server and arrives already decided. So a copy served from a static host
+      — GitHub Pages included — paints an empty grid and says "disconnected"
+      until it is pointed at one.
+
+      Two servers are possible. `improvise-ws-server`, which exists, is a
+      native process you run yourself; pass its address as ?ws=ws://host:port.
+      The in-page worker (improvise-9x6), which does not exist yet, is what
+      makes this page standalone. Until it lands the honest description of a
+      Pages deployment is "the delivery pipeline, carrying a client with
+      nowhere to connect" — which is why this notice is static HTML rather
+      than something app.js decides: it is true on every load, and a page that
+      cannot reach a server cannot be trusted to explain why.
+    -->
+    <p id="backend-notice">
+      improvise in the browser is a thin client: the document lives in a
+      server. Run <code>improvise-ws-server model.improv --port 8787</code>
+      and reload with <code>?ws=ws://127.0.0.1:8787</code>. Served over
+      https, a <code>ws://</code> address is blocked as mixed content — use
+      <code>wss://</code> or a local http server. Running with no separate
+      process at all is the in-page worker (improvise-9x6), and it is not
+      built yet.
+    </p>
+
     <main>
       <aside id="categories" aria-label="Categories"></aside>
       <div id="grid" tabindex="0" aria-label="Grid"></div>

web/style.css

@@ -139,3 +139,17 @@ td input {
   color: inherit;
   background: transparent;
 }
+
+/* The page cannot reach a server from a static host, and says so. */
+#backend-notice {
+  margin: 0;
+  padding: 0.5rem 1rem;
+  border-bottom: 1px solid var(--line);
+  background: color-mix(in srgb, var(--accent) 10%, transparent);
+  font-size: 0.85rem;
+}
+
+#backend-notice code {
+  background: color-mix(in srgb, var(--line) 45%, transparent);
+  padding: 0 0.25rem;
+}