The shooter's entry sheds its second concept: posting a result becomes its own module #251

The second of three sequenced extractions from src/client/main.ts (1,239 lines), after the buy panel. This one takes the result posting: main.ts:632-730, the block under // --- results, sent as the match goes rather than only at the end.

Done looks like

• [ ] A module named for the one thing it does: turning a match's state into a result, posting it, and dealing with what comes back — including the retry #203 added and the pending queue in src/client/pending.ts, which it should own rather than sit beside.
• [ ] Plain data in and out: it takes the world's numbers and a fetch-shaped function (the Host already has one, which is how it is tested without a network), and hands back what happened. No document, no globals.
• [ ] The same behaviour, exactly: posted as the match goes rather than only at the end, the same body the server's gate accepts (src/result.ts), the same retry, the same "not posted" message where the page shows one, and the same map recorded with it (#240).
• [ ] main.ts keeps the wiring and nothing else.
• [ ] The tests move with the code, and one of them would fail without this: a stubbed fetch that fails once and then succeeds still lands exactly one result.
• [ ] The pull states the bundle before and after; no ceiling moves.

Files I expect to change

A new src/client/report.ts (or a better name) and its test, src/client/pending.ts, src/client/main.ts, src/client/main.test.ts.

Risks

• It waits for the buy panel's extraction only to avoid two pulls rewriting the same file at once.
• A move, not a rewrite: the retry and the queue are load-bearing for a player on a bad connection, and their tests are the contract.

Suggested: whoever took the first of the three, immediately after.