Every preview opens on a table mid-negotiation: a seeded game a reviewer can read in ten seconds #80

Intent. Make a preview show the game instead of an empty lobby, so the work that is about to land — the page (#75), the terminal (#78), the tools (#76), the lapse (#77) — can be reviewed by opening a link.

The split. #45 seeds RULES.md §10's worked table and waits on #10 so that the demo can show a settled table with its reveal. A table mid-negotiation needs none of that: everything it takes has been merged since. Measured today (63a4041): a fresh preview's lobby is empty, and seeing a played table takes four signed identities and eight curl calls — which is exactly what I did to review this round. This issue is the mid-game demo; #45 keeps the settled one and the reveal.

Done looks like

• [ ] On boot, when FORGE_APP_ENV is preview (never production, never local unless asked) and the database holds no table, one table is seeded: four seats held by named demo players, started on a fixed seed so the charter is the same every time, with a handful of acts already played — an offer, an acceptance with its sworn aim, a pass — leaving a standing offer and a seat to act.
• [ ] It is honestly labelled. The table's title says it is a demo, the lobby and the table page say a demo table is not a game anyone is playing, and README.md says what is real and what is seeded.
• [ ] The demo seats are not people: their identities cannot be signed in as, they hold no forge account, and a real visitor can still watch the table and cannot take one of its seats. A visitor who wants to play opens their own.
• [ ] It is the app's own actions that build it — openTable, joinTable, startTable, makeOffer, acceptOffer, passTurn with an injected identity — never SQL written a second time, so the demo cannot drift from the rules or hide a bug the actions would have caught.
• [ ] It happens once: a second boot on the same volume adds nothing, and the seeding is skipped in a millisecond when a table already exists.
• [ ] Tests that fail without it: seeding an empty database in preview produces a playing table with a standing offer and a seat to act; seeding it twice produces one table; production and the test environment seed nothing.

Files I expect to change. src/server.ts (the one call at boot), a new src/demo.ts, src/server.test.ts, README.md.

Risks. It must never run against production data — key it on the environment and on emptiness, and say so in the module comment. Seeding is work done before the first request, so keep it to milliseconds. A demo charge is still a charge: it is redacted like anyone's, and #63's property test must pass over the seeded table too.

Who. @mason, reviewed by @juniper. Ready now.