Find a burst weapon wherever it is on the rack, not just in the first five

endBurst looked its tin up with [0, 1, 2, 3, 4].find(...) — correct for exactly
as long as the rack held five slots. Growing RACK_MAX to 9 meant a burst weapon
picked up into slot 5..9 could never be found, so it was never spent: you fired
it and the count stayed where it was, forever. Oliver hit it with the beacon, the
rocket and the flamer, which together with the gun are precisely the four
kind:'burst' weapons — endBurst is the only spend path that searched for its slot
instead of being handed one.

The serve weapons were never affected, and that is the tell: bomb, triple, fire
and the laser all spend through spendSlot(G.weapon), the live index. Checked the
laser end to end at slot 8 rather than reasoning about it — 6, 5, 4, 3, 2, 1,
gone.

Fixed at the invariant rather than at the call site. The rack has always had a
comment saying everything reads through the slot accessors so nothing else needs
to know how it is stored; slotOf(id) is now the fourth one, and it is the single
place that knows the range. Verified all four burst weapons arm from a real tap
in slots 5-8 and leave the rack when the burst expires.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

HANDOFF.md

@@ -1172,6 +1172,19 @@ scaled so the BODY matches the standing frame (98% of sprite height) and the rac
 this on any new pose with a raised prop.
 
 ## Gotchas learned the hard way
+- **Nothing outside the four slot accessors may know how many slots there are.** `endBurst` had
+  `[0, 1, 2, 3, 4].find(i => slotId(i) === id)`, which was correct for exactly as long as the rack
+  held five. `RACK_MAX` 4 → 9 and a burst weapon in slot 5..9 was suddenly unfindable, so it was
+  never spent: beacon, flamer, rocket and gun sat at their pickup count forever. Use `slotOf(id)`.
+  The serve weapons were untouched because they all spend through `spendSlot(G.weapon)` — the LIVE
+  index, never a search — which is why the laser looked fine while the other four did not.
+  Note also that spending re-indexes the rack (`spendSlot` splices), so a slot number goes stale the
+  moment any tin empties. Look weapons up by ID, not by a slot you cached a frame ago.
+- **A test that walks the game forward will quietly kill the player.** Three separate diagnostic runs
+  above returned nonsense (`stillCarried: true`, no laser fired at all) purely because `G.mode` had
+  become `'eaten'` several steps earlier and every gameplay entry point bails on that. When a probe
+  says a feature is broken, check `T.G.mode` before believing it. `setInterval(() => T.zombies.length = 0, 30)`
+  for the duration of the test is the cheap fix.
 - **Stale ES modules are the #1 time sink.** python http.server sends no cache headers, so an edited
   module often loads STALE. `preview_stop`/`preview_start` only helps if the port actually changes,
   and holding 8641 with a throwaway socket **did not work reliably**. What DOES work: