What a room costs, measured before anything is built on it: the world stepped headless in this process, at a ceiling a test holds #302

#300 asks for multiplayer, and the first thing that decides its shape is a number nobody here has: what one match costs when this process steps it rather than a browser. Everything else — how many rooms a deployment holds, how often a snapshot can go out, whether the server can be the truth at all — follows from it, and guessing it would be designing on a hope.

The simulation already runs headless in Bun: src/client/replay.ts steps a seeded world through a script in the suite, and src/rl/arena.ts steps ninety-six of them for training. So this is a measurement, not an invention.

Done looks like

• [ ] One command measures it: a bench that builds a real createWorld with ten players, runs update at the game's 64 Hz tick for a stated number of simulated seconds, and prints milliseconds of CPU per simulated second per world, with bots thinking and with bots idle so the policy's share is visible.
• [ ] It prints how many such worlds one core holds at 64 Hz with a stated margin, and what that number becomes when the trained policy is loaded versus when it is not.
• [ ] It prints the size of a snapshot of that world — ten players, the grenades, the bomb, the round clock — in three encodings a wire could use: JSON, JSON gzipped, and a packed binary of quantised fields; and the bytes per member per second at 8, 16 and 32 snapshots a second for each.
• [ ] The finding is a ceiling the suite holds, in the idiom src/budget.test.ts already uses: a test asserts a world-second costs under a stated millisecond figure in this process, so the day somebody makes the simulation twice as expensive it is red here rather than discovered in a room.
• [ ] The pull states every number it measured, on what machine, and answers the one question this exists for in a sentence: how many rooms one deployment of this app can hold, and at what snapshot rate.
• [ ] Nothing about the game changes. No route, no socket, no new dependency; if the bench needs a seam to step a world without a page, it uses the one the replay tests already use.

Files I expect to change

scripts/room.ts (new, or a section of scripts/bench.ts if #20 has landed by then — read it first and extend rather than duplicate), a test under src/ holding the ceiling, README.md's command list.

Risks

• A bench that measures the wrong thing is worse than none: step a real world with a real policy, not a stub, and say what you excluded.
• Do not let the snapshot encoding become a design decision here. This issue measures three candidates; #303 picks one and says why.
• The forge's box is shared, so a number from a laptop is not a number from production. State where it ran.

Suggested: Torque.

Correction to a cross-reference in the body above: the snapshot encoding is chosen in #304 (a room you can watch), not in #303, which is the relay and stays out of the game entirely. This issue measures the three candidates; #304 picks one and says why.

Half of this arrived with pull #312 rather than before it: the snapshot's size is pinned by a test and the packed encoding won against JSON on measured numbers (544 B against about 3.4 kB), and src/rooms/hub.ts states a room's CPU cost from src/budget.test.ts. What is still missing is what this issue exists for: the bench — ms of CPU per simulated world-second with bots thinking and idle, worlds per core at 64 Hz, and the ceiling as a test — now with a real Room to measure instead of a hypothetical one. Worth doing before ROOM_CAP is ever raised.