test: automated responsive-layout harness (closes #13)

Verifies the mobile layout from #5 with a real browser engine instead of
by hand on a phone. make frontend-viewport-test builds dist/, serves it
from the same digest-pinned nginx image and the same nginx.conf the
shipping container uses, and drives a digest-pinned headless Chrome
against it over CDP.

Viewport widths are derived from the app's own CSS rather than from a
list of phone models: the @media conditions in src/styles.css and any
Tailwind responsive prefixes in the markup are parsed, and each
breakpoint is tested one pixel below, exactly on, and one pixel above.
max-width: 768px matches at 768, and a generic 375px test sails past
that boundary entirely. Four anchor viewports are added with stated
reasons: a 320px floor, a desktop baseline, and two phone-landscape
sizes straddling the breakpoint.

Assertions are on computed layout, not screenshots: horizontal overflow,
elements past the viewport edge, clipped text (deliberate ellipsis
truncation excluded), 44x44 minimum tap targets, and genuine reflow of
the host rows checked on both flex-direction and geometry. Probing and
gateway detection are asserted to still run at narrow widths, since the
early-return mobile path rejected in #8 is what would silently regress.
Screenshots are written to tmp/viewport/ as artifacts alongside the
results, not as the evidence.

puppeteer-core rather than playwright: it is the one variant of either
that never downloads or bundles a browser, so the browser stays a
digest-pinned image and the npm side is pinned by yarn.lock integrity.

The browser container runs on an --internal docker network with no route
off the host; the harness answers the app's latency probes itself from a
fixed delay table so the rows render a realistic spread of value widths.

Kept out of make check: it needs Docker and takes minutes, where make
test has to stay under 20 seconds.

The harness was observed failing before being trusted, twice: a planted
900px fixed-width element in a host row, and the mobile reflow rule
neutered. Both reverted.

Against the current layout it reports two real defects, filed as #42
(horizontal overflow at 320px) and #43 (tap targets below 44x44).

README.md

@@ -41,11 +41,25 @@ provide:
 - `script/fmt` — format all files (writes)
 - `script/fmt-check` — check formatting (read-only)
 - `script/check` — run test, lint, and fmt-check
+- `script/frontend-viewport-test` — responsive-layout verification of the built
+  frontend in a containerised headless Chrome (see
+  [test/viewport/README.md](test/viewport/README.md)). Not part of
+  `script/check`: it needs Docker and takes minutes.
 - `script/docker` — build the Docker image tagged via `script/projectname`
 - `script/cibuild` — CI entrypoint: plain `docker build .`
 - `script/precommit` — run by the git pre-commit hook; runs `script/check`
 - `script/install-precommit` — install the git pre-commit hook
 
+## Responsive layout
+
+The narrow-viewport layout lives in the `max-width: 768px` media block in
+`src/styles.css`. It is verified automatically by `make frontend-viewport-test`,
+which drives a digest-pinned headless Chrome against the built `dist/` and
+asserts on computed layout at widths derived from that CSS — one pixel either
+side of every breakpoint it declares, plus a 320px floor, a desktop baseline and
+two landscape sizes. See [test/viewport/README.md](test/viewport/README.md) for
+what it covers and what it genuinely cannot.
+
 ## Rationale
 
 When debugging network issues, it's useful to have a persistent at-a-glance view