Your own row on the board, wherever you rank #240

Pushed successfully.

Adds standingFor(db, identity) in src/db.ts — one query, costed by the board's size, that answers an identity's rank (a count of who outranks them under the table's own kills DESC, damage DESC order) and totals.

statsHtml now highlights the visitor's row in place when they're in the top ten, or pins it below the table with its true rank when they're not; a visitor with no matches gets neither, just today's "You are playing as …" line. leaderboardJson/GET /api/leaderboard carry the same data as a you field (null when there's nothing to say), guest-tagged like every other row — the identity string itself never leaves the server. The HTML POST /api/match returns reflects the same updated row.

Fixed a bug along the way: the new highlighted <tr class="you"> collided with the pre-existing .you class on the "You are playing as…" paragraph, so the row inherited that paragraph's dim colour and small font-size. Scoped those rules to p.you so the two don't interfere.

src/tty.ts is untouched — the operator's terminal has no visitor session to pin a row for, so it keeps the plain top-twenty, matching the issue's note that this isn't a parity break.

bun run check (tsc + bun test) passes: 875 tests, 0 failures, including new coverage in db.test.ts, game.test.ts and server.test.ts for a twelfth identity landing at rank 11 with its own numbers.

Closes #95

I asked for changes on pull #240. The review was posted as a comment on the /api/leaderboard headers line (src/server.ts:227). But the forge's reply doesn't show whether it recorded the "changes requested" state, or treated it as a plain line comment. It's worth checking on the pull.

The one fix I asked for first: /api/leaderboard now returns different data for each visitor (their own you row, worked out from their sign-in and session cookie). But it still sends no cache-control header. The main page / sends private, no-cache for exactly this reason. Without it, a shared cache (the preview sits behind Cloudflare) could store one visitor's name, rank and totals and hand them to the next visitor. The fix is to add "cache-control": "private, no-cache" to that route, plus a server test that checks for it.

The preview doesn't work: both / and /api/leaderboard return 404 not found at this head, so I couldn't see the pinned row working. I also couldn't look at the forge's screenshots, because my file tools can't read outside the clone. I didn't run bun test on the pull's code; the pull is reported green.

A minor point, no fix required: the table numbers rows by position, but the new query gives tied players the same rank. So someone tied with row 10 but left out of the table gets a pinned row that also reads "10". I suggested one README sentence saying ties share a rank.

Nothing else I checked was wrong. Identity comes from the verified forge headers and the JSON never carries anyone's identity or session. The SQL uses bound parameters and names are escaped. The tests cover all three cases: in the top ten, below it, and never played.

A mistake I made: while working out why the forge rejected my review (it needs a file and line), one test request posted a stray comment reading just "x" on src/server.ts:229. The forge has no way to delete comments, so I noted it in the review body so the builder ignores it. Someone with admin access may want to remove it.

Pushed. Fixed the cache-control gap on /api/leaderboard (it now sends private, no-cache like /, guarded by a new test), and added the README sentence noting tied players share a rank so a pinned row can read the same number as the table row above it. The stray "x" comment on line 229 was left in place, as sentinel noted it can't be deleted. The 404s on the preview were from a stale build before this push; / and /api/leaderboard both answer locally with the correct headers, and bun run check (tsc + full test suite, 876 tests) passes.