The HUD is pinned before it moves: src/client/hud.test.ts says what a player sees today #64

src/client/hud.ts is 256 lines of drawing with no test of its own — the largest such module in the game — and #18 is about to move half of it onto the engine's overlay tools that landed in #49. Pin it first: a test that says what the HUD draws today is the only thing that can tell a move from a change.

Ready now, and it opens hud.ts itself only if the test finds a bug: this is the same order #53 and #57 set, a net before a move.

Done looks like

• [ ] src/client/hud.test.ts drives drawHud with a recording Paint — the engine's Paint from the door if it fits, the HUD's own if it does not, and the pull says which and why — and needs no canvas, no document and no browser.
• [ ] It pins what a player sees, not how the code is arranged: health drawn red below 30 and white above, ammo reading mag / reserve with the reload state shown, the clock reading --:-- outside the timed phases and red once the bomb is planted, the crosshair's gap growing with inaccuracy and returning to 4 + spread * 14 at rest, the use bar's fraction following useProgress, a kill-feed entry drawn at 8 seconds old and not at 8.1, the scoreboard sorted by kills then damage with the player's own row marked, and a dead player told they are watching.
• [ ] Layout survives both ends: at 360px and at 1920px nothing is drawn outside the canvas, the font sizes scale the way the code says today, and the same world at two sizes draws the same number of calls.
• [ ] It is a pin, not a transcript: assert the calls that carry meaning — text, colour, fraction, order between panels — and do not assert every coordinate of every rectangle, or #18 will delete this file instead of using it.
• [ ] A world is built once for the suite from the existing helpers rather than a fresh fixture per test, and the file says at the top what it is for: "this test exists so #18 can move the HUD onto the engine's overlay and prove it drew the same thing".
• [ ] If the test finds real wrongness — a colour that never triggers, a phase that draws nothing, a feed entry that lingers — fix it in hud.ts in the same pull and say so; that is a win, not a detour.
• [ ] bun test green, and the pull states how many assertions the HUD now has and what main.test.ts was already covering so the two do not duplicate each other.

Files I expect to change

src/client/hud.test.ts (new), src/client/hud.ts only if the test finds something wrong, README.md only if it claims the HUD is untested.

Risks

hud.ts imports MOVE from physics.ts, which #62 renames to CS_MOVE in src/client/movement.ts: import the name, never a literal, and expect a one-line rebase if #62 lands first. The other risk is a test so exact that it pins the current arrangement of panels rather than the game's readout — write the assertions as sentences a player would recognise, and if one cannot be written that way, leave it out.

Suggested: Torque — a recording stub, no browser, and a pin that makes someone else's move safe is exactly that brief.