A match has a page you can link to, and a link to this app looks like something #91

A match here is a row in a feed that scrolls away in eight entries, and the app calls itself "a scoreboard among friends" — but there is nothing to send a friend. There is also nothing to look at when you do: src/pages/shell.ts emits a <meta name=description> and nothing else, so every tab shows a blank page icon and every link pasted anywhere shows a bare URL. Both are small, and both are what the app looks like to someone who did not start here.

Done looks like

• [ ] /match/<id> is a page: the score, the side, the kills, deaths, headshots and damage, the rounds, whether it finished, when it was played and whose it is — server-rendered through the same shell, escaped the way every other page is, with the nav and the security floor unchanged.
• [ ] An id that is not a match is a 404 that says so and points at the games, not a 500 and not a blank page; an id that is not the shape of an id is refused before it reaches the database; nothing about the match id lets a caller read anything else.
• [ ] The match feed on / links each row to its page, so the path to it is the one a player already looks at.
• [ ] It is public and says what it is: a match page names the player the way the leaderboard does — a guest's is marked a guest's — and carries nothing the leaderboard does not already show. No session, no cookie, no writes.
• [ ] The app gets a face, generated like everything else here: an SVG favicon built in code and served from its own route with a year of cache and the security floor, a theme-color, and Open Graph and Twitter card tags on every page — title, description and site name from src/games.ts, so a third game gets its card from its registry entry and a match page gets one that names the score.
• [ ] No asset files: the icon is produced by a function with a test that says what it draws, in the spirit of the map, the textures and the sounds. No image binary is committed.
• [ ] src/server.test.ts would fail without this: the match page answers 200 with the right numbers and escapes a hostile name, a missing id is 404, a malformed id is refused, the icon route answers with image/svg+xml and an immutable cache header, and both games' pages carry their card tags.
• [ ] / is no slower and no larger than it needs to be: the pull states the bytes the head grew by and the time to first byte before and after.

Files I expect to change

src/pages/match.ts (new), src/pages/shell.ts (the head: card tags, icon link), src/pages/shell.test.ts, src/pages/game.ts (the feed's links), src/db.ts (one query by id), src/db.test.ts, src/server.ts (two routes), src/server.test.ts, src/games.ts if a card needs a field, README.md.

Risks

The trap is turning a match id into a capability: ids are handed out by the browser that played the match and the id is now a public URL, so the page must show only what the leaderboard already shows and the ownership rules in saveMatch must not be weakened by a read path. The second is the card: Open Graph wants an absolute URL, which means FORGE_APP_URL and a sensible answer when it is unset — decide it, do not guess it at request time from a header a caller controls. Third, keep the icon small and dull; a generated SVG is a few hundred bytes and anything more is a hobby. This lands in src/pages/game.ts and src/db.ts alongside #89, so it goes after it.

Suggested: Torque — the server, the database and the page tests are theirs.

Planner's note, for whoever takes this after #89: once #93 records a match's inputs, the page this issue asks for is the natural home for watching it back — one page, a link, and a canvas that replays the round rather than a table of numbers about it. #168 then uses the same recording to verify the result the page is showing. Worth reading those two before designing this page's shape.