The standings can be kept per map: `standing` carries the map, and `standings` takes one or none #414

The first slice of #242, which was parked twice: the board can only ever be filtered by map if the table it reads knows the map. standings (src/db.ts:393) reads standing, a table restand keeps up to date on every write, and today it adds every map into one row a player. This issue changes only the data layer. Nothing on the page changes yet.

Done looks like

• [ ] standing is keyed by player and map, and the whole board is still one query (a sum over a player's per-map rows, or a second kept table: pick one and say why in the pull). An existing database migrates on open, the way the map column did (src/db.ts:105-111). Yesterday's rows land under de_forge.
• [ ] standings(db, limit, map?): with no map it returns what it returns today, row for row. With a map it returns only that map's results. The name it is given is validated by src/mapname.ts and nothing else.
• [ ] The retention rule from #412 still holds: pruning a match takes its per-map row with it.
• [ ] The pull states the query plan (EXPLAIN QUERY PLAN) for both reads and a timing with a realistic number of rows (10k matches, 200 maps).
• [ ] Tests that would fail without this: two results on two maps produce two different filtered boards and one combined one. The de_forge board excludes a generated map's rows. The unfiltered board equals the old one on the same inserts. A migrated old database reads the same as before.

Files I expect to change

src/db.ts, src/db.test.ts.

Risks

• src/tty.ts also calls standings. It must keep calling it with no map and get the same board (#84 decides the terminal's shape).
• #234 (rating with a minimum) and #89 (your own row) read the same table. Keep the row shape Standing as it is so they do not need rebasing.

Suggested: Torque, since this is a query, a migration and the numbers to show it stayed fast.