The leaderboard runs off a phone: seven columns in 360px, and `wins` is the one that goes #141

The leaderboard table is wider than a phone, so the last column falls off the right edge of the first page a person sees.

statsHtml in src/pages/game.ts:50 emits a seven-column <table> — # player matches kills K/D HS wins — and the only styling it gets is table { width:100%; border-collapse:collapse; font-size:.9rem; } (src/pages/game.ts:213) with th, td padded .35rem .5rem. width:100% cannot shrink a table below the sum of its columns' minimum content, and a row like guest 712d [guest] plus six numeric cells does not fit in 360px. The forge's own screenshots of / at 390px show wins cut at the edge, on main and on every open pull — this is not #122's doing, I just saw it twice while reviewing it.

AGENTS.md asks for 360px with no horizontal scroll, and this is the page that greets everyone.

Done looks like

• [ ] / at 360px has no horizontal scroll and no clipped column, checked at 360 and 390.
• [ ] The numbers stay readable — shrinking the font until it fits is not the fix.
• [ ] Whatever the shape is (a scroll container around the table with the rank and name pinned, fewer columns below a breakpoint, or a stacked card per player under ~420px), the desktop table is unchanged.
• [ ] A test in src/pages/game.test.ts that would fail if the markup lost it — the wrapper, or the columns a narrow layout drops.

Files I expect to change

• src/pages/game.ts (the table markup and its CSS), src/pages/game.test.ts.

Confirmed against 979c388: table { width:100%; border-collapse:collapse; font-size:.9rem; } at game.ts:213, th, td padded .35rem .5rem at :214, and the only breakpoint in the sheet is @media (max-width: 640px) { #stage { aspect-ratio:4/3; } h1 { font-size:1.2rem; } } at :225 — nothing there touches the table, and nothing anywhere sets overflow-x. Seven columns and a guest tag in 360px is exactly as you describe.

One planning note for whoever takes it: #95 rewrites the same table — it adds the visitor's own row wherever they rank, which means a row that may not be in the top ten and probably wants marking as theirs. The two should not run concurrently. #141 first is the right order: it decides what the table is at 360px (which columns survive, and how), and #95 then puts a row into a layout that exists rather than into one that is about to change under it. Worth saying in whichever pull lands first.