The day itself is not a run: a result posted under the match-of-the-day id is refused, not enthroned #263

Probing today's board on a fresh database, I posted a result whose matchId was the day itself — 20260921, the id the menu fills in and the link carries — and the server took it (200). It is now a row on today's board, in the all-time standings and in the feed, owned by the session that sent it: nobody else can replace it, and its owner can rewrite it whenever they like. Two further posts from other sessions got 409, which is the ownership rule working exactly as designed on a row that should never have existed.

The design around it is right — dayFiled(id, now) gives each run its own id under a day column, and dayBoard keeps one best run per player — which is precisely why the bare day id is not a run and should not be accepted as one.

Done looks like

• [ ] A result whose id is the day itself is refused at the boundary with the same 422 an impossible result gets, and the rule is stated where the grammar lives (src/daily.ts beside dayFiled/dayOfMatch, or src/result.ts where the gate is) rather than in the route.
• [ ] A run filed under the day is still accepted exactly as it is today, and the pull says what shape a legitimate daily result has.
• [ ] Anything already in a database under the bare day id is dealt with — ignored by dayBoard and by the standings, or migrated — so a deployment that already has one does not keep it on the board for ever. src/db.ts migrates additively today and has a test for a database written before a column existed; follow it.
• [ ] The same question is asked of the other ids the client can send: the pull states what isMatchId accepts now that the day widened it, and whether any other reserved shape can be claimed the same way.
• [ ] Tests would fail without this: posting the day id is 422; posting a run filed under it is 200; a database seeded with a bare day row shows nothing from it on today's board; and the ownership test keeps passing for real runs.

Files I expect to change

src/daily.ts, src/result.ts, src/db.ts if a seeded row has to be excluded, src/server.ts only if the refusal belongs there, and the tests beside each.

Risks

• This is a boundary rule, not anti-cheat: a browser can still claim a run it did not play, which is #168 and stays there. What this fixes is the one id that cannot be competed for, and it is worth fixing precisely because #261 just gave the board something to win.
• Do not narrow isMatchId so far that the day's match stops being playable from a link — /?match=20260921 must keep working; it is the result that is refused, not the match.

Suggested: Torque — a boundary, a migration and a test for each.

Confirmed on the second gate too: POST /api/run with runId: "20260921" — the day id — is accepted (200) and lands on the range board as a run, because parseRun asks isMatchId the same question parseResult does. So the "what else can be claimed" checkbox in this issue is not hypothetical: whatever rule lands here should be asked of every gate, which is now a table in src/server.ts (#265).

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.