CB-WP-0018-T01: the browser sees the end of its own game

Server::serve_end plus doc::ending, wired into both of run_game's exits.
Where the browser used to get Connection refused it now gets the ending
page with the result and the final table. It serves until the page posts
'done' (the page carries a close control), with a 600s linger so an
abandoned tab cannot hold the process open.

document() split into body() and move_section() so the ending shows the
same table rather than a second rendering of it.

The control had to be built twice and the first was worthless:
the_end_of_the_game_reaches_the_browser calls serve_end directly, and
deleting the call from run_game left it GREEN -- it tested the link and
not the chain, which is CB-EV-0012's finding recurring.
a_real_game_played_to_its_end_leaves_the_ending_on_screen runs the real
play() with a browser seat, drives a real game to its end over a real
socket, and goes red under that mutation printing an empty page -- the
reported symptom exactly.

A weak assertion of mine caught by itself: the first draft grepped the
page for location.reload, which would have forced a second script to
satisfy a test rather than a requirement. It now asserts the ending
endpoint cannot answer 'ok'.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/CB-WP-0018-the-browser-is-a-client.md

@@ -58,7 +58,7 @@ refuses to say what happened and the player is left to infer it.
 
 ```task
 id: CB-WP-0018-T01
-status: todo
+status: done
 priority: high
 ```
 
@@ -80,6 +80,44 @@ asserts the final GET returns a page naming the outcome, **not** a refused
 connection. And the error path, driven by a game that fails, asserting the
 reason reaches the page.
 
+**Done 2026-08-03.** `Server::serve_end` plus `doc::ending`, wired into
+both of `run_game`'s exits. Verified live: where the browser used to get
+`Connection refused` it now gets an 8,998-byte page reading *"GROUND —
+game over … 30 commands, hash f6c890a65271"* with the final table.
+
+**How it ends:** it serves until the page posts `done` — the ending page
+carries a *"close — I have read this"* control — with a 600 s linger as
+the bound, so an abandoned tab cannot hold the process open and a player
+reading the result is not raced by a timeout.
+
+`document()` was split into `body()` and `move_section()` so the ending
+shows the **same** table rather than a second rendering of it; two
+renderings of one state is how they drift.
+
+**The control had to be built twice, and the first one was worthless.**
+`the_end_of_the_game_reaches_the_browser` calls `serve_end` directly —
+and deleting the call from `run_game` left it **green**. It tested the
+link and not the chain, which is CB-EV-0012's finding recurring
+(*"every link was tested and the chain was not"*).
+
+`a_real_game_played_to_its_end_leaves_the_ending_on_screen` runs the real
+`play()` with a browser seat, drives a real game to its end over a real
+socket, and requires the last page to be the ending. Under the same
+mutation it goes red — and prints an **empty page**, which is exactly the
+symptom that was reported.
+
+A second control: a game that ended badly says why and draws **no** table,
+because drawing a table for a game that never happened is the same lie the
+empty page told.
+
+**And a weak assertion of mine, caught by itself.** The first version
+grepped the page for `location.reload`. The ending page reuses `SCRIPT`,
+whose reload is guarded by `t.indexOf('ok') === 0`, and the ending
+endpoint answers `closed` — so the grep would have forced a second script
+to satisfy a test rather than a requirement. That is the source-text
+control shape ADR-0010 D2 demoted. It now asserts the endpoint cannot
+answer `ok`.
+
 ## The second report, and what it actually is
 
 Reported: *"the cards I play by pulling them on a target will not be