docs: a landing page, served beside the app rather than in front of it

improvise-e61. Vanilla, single file, 192 lines, no build step: the four casts
improvise-d4w recorded, played by asciinema-player pinned from jsdelivr.

improvise-kh8 recorded a collision to resolve before starting — Pages already
serves the standalone web app at the root, so a landing page either replaces
it, sits beside it, or is dropped. It sits beside it at `/landing/`, because
kh8's own note is right that the live app is the better front door, and a page
the deploy never copies is a file nobody can reach. `web/assemble.sh` copies
it, so the browser harness serves the same tree the deploy publishes and there
is still one answer to "what ships".

The player config deviates from the tickets, deliberately. improvise-d4w's
description and improvise-e61's criteria both say 100x30; every cast header
says 120x37, so the recordings never complied with their own ticket. A 30-row
player clips the bottom seven rows of a 37-row cast, which is exactly where
the tile bar and the status line are, so the page declares the geometry the
casts actually have.

e61 also asked for the casts to be checked against the current UI before
embedding. They were: the tile bar's short_label vocabulary and the mode line
still match, but the casts predate improvise-2zq's `+cat` column by five
months and every one of them opens on the recorder's shell prompt. Filed as
improvise-2oxt rather than silently embedded as current.

Verified by driving the page in Chromium: four players construct, each renders
37 terminal lines after play, no failed request and no page error — against
both `docs/` directly and the assembled `site/landing/`. Counting the players
alone was proved worthless first: with autoPlay false the cast is not fetched
until the click, so a page whose every cast path 404s constructs four players
and throws nothing. Breaking `./casts/` to `./cats/` passes the construction
check and fails the play check with four 404s. improvise-bgtf carries that as
a harness spec, since nothing in CI asserts any of it yet.

README: `cargo install improvise` was false — the crate is not on crates.io —
and the Pages description named two of the three gates a deploy waits on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

web/assemble.sh

@@ -39,6 +39,15 @@ cp -f "$root/web/index.html" "$root/web/app.js" "$root/web/style.css" "$root/web
 # which writes them through the VFS — so leaving it out is an empty grid, not
 # a 404 the page could report.
 cp -f "$root/web/demo.improv" "$out/"
+
+# The landing page (improvise-e61), beside the app rather than in front of it:
+# the live app is the better front door, and a page the deploy never copies is
+# a file nobody can reach. Its cast paths are relative, so `docs/` and
+# `site/landing/` serve the same file unchanged.
+mkdir -p "$out/landing"
+cp -f "$root/docs/index.html" "$out/landing/index.html"
+cp -rf "$root/docs/casts" "$out/landing/casts"
+
 cp -rf "$root/web/pkg" "$out/pkg"
 cp -rf "$root/web/worker-pkg" "$out/worker-pkg"
 rm -f "$out/pkg/.gitignore" "$out/pkg/package.json"