A result says which map it was played on, so the leaderboard is comparing like with like #150

Matches on de_forge and matches on a map generated ten seconds ago now land in the same table, and nothing anywhere records which was which.

src/result.ts validates what a browser reports and src/db.ts stores it; neither has a field for the map. So the recent-matches feed cannot say where a match was played, a player cannot find the map they had a good round on, and the standings mix layouts silently. The map's name is already a short validated string (de_forge, or gen_ plus base36) — it is the cheapest column this table will ever gain.

Waits for #101, which gives src/result.ts the test file it never had; this adds a field to it and should land on top of that rather than beside it.

Done looks like

• [ ] parseResult accepts a map field, validated at the boundary like everything else: a short string, de_forge or gen_<base36>, anything else refused with the 422 the route already answers; a body with no map is still valid and records the default, so an older client keeps working.
• [ ] src/db.ts gains the column with a migration in the same shape as the identity migration already there, and a database written before this keeps its rows and calls them de_forge.
• [ ] The recent-matches feed on / names the map, escaped where it is rendered.
• [ ] The terminal's match list shows it too — what a person can do on the page they can do there.
• [ ] Tests: a result naming a generated map round-trips; a result naming something absurd is refused; an old row reads as de_forge; opening a database twice migrates once, which is the assertion db.test.ts already makes about the last migration.
• [ ] The standings keep meaning what they say today — this issue adds the fact, it does not split the leaderboard. If a person later wants per-map standings, that is another issue and this is what makes it possible.

Files I expect to change

src/result.ts, src/result.test.ts, src/db.ts, src/db.test.ts, src/pages/game.ts, src/terminal/screen.ts, src/client/main.ts (it posts the field), src/server.test.ts.

Risks

• The map name comes from the browser and is therefore a claim, like every number in a result. It is validated by shape, not trusted — and the pull says plainly that a client could lie about which map it played, exactly as it could about its kills.
• Keep the migration additive and nullable; a deploy that cannot read yesterday's database is worse than a missing column.

Suggested: Torque — a schema, a boundary and a migration.