Stage 4: upgrades, and a quartermaster to spend them at

Every level banks one choice. Choices queue, and are spent at an NPC in the
hub: walk to it, press E, take one of three weighted options. Seven upgrades,
all data — split shot, glass cannon, spread, sniper, doubleshot, poison,
eraser — and SimWorld gained no per-upgrade branch to run any of them.

The four ambiguities in the brief were settled with the user first, since
each changes what gets written:

  damage      base x (1 + sum additive) x product multiplicative. The flat
              +5% every upgrade carries, spread's -10%, doubleshot's -50%
              and glass cannon's +100% pool; sniper multiplies on top, so
              two snipers is 4x and not +200%.
  glass       half the LEVELLED maximum, multiplying if taken twice, so the
              price does not fade to a rounding error by level 15.
  poison      independent stacks, not a refresh.
  split       +/-45 degrees from the original heading.

Independent poison stacks sound expensive and are not: every dose lasts the
same number of ticks, so doses expire in the order they were added, the
pending expiries are a plain FIFO, and PoisonTrack only ever looks at its
front. O(1) per actor per tick however many are live.

Stats are derived from the upgrade list and never stored, the way level is
derived from experience -- a saved stat cannot disagree with the upgrades
that produced it. Upgrade riders (split charges, poison, erase chance) travel
on the bullet instead, because a shot in flight has to keep what it was fired
with rather than gaining Poison because the shooter just took it.

Two invariants this collided with, both now pinned:

  - bullet speed gained a ceiling. Wall collision samples once per tick, so
    anything over a tile per tick tunnels; two snipers asked for 2480 u/s
    against a 1920 threshold, and a tunnelling bullet looks like a bullet.
  - BULLET_INTEREST_RADIUS rose to 2900, because an upgraded player shot is
    now the longest-travelling bullet in the game. test_interest measured
    the worst case from static content, which upgrades quietly invalidated.

Choosing is intent checked three ways: a choice must be owed, the index must
name one of the three options the SERVER put on the table, and the player
must be standing at the NPC. The offer is rolled once and persisted, so
closing the screen is not a reroll and neither is a crash.

tools/diag_upgrades.tscn covers level -> banked choice -> refused in a
dungeon and refused across the room -> taken at the NPC -> new stats ->
on disk. Bots never walk to the quartermaster, so the smoke test cannot.

Known gap recorded in the roadmap: at PLAYER_BULLET_DAMAGE = 6, the +5% the
first upgrade carries rounds back to 6 and visibly does nothing. It comes out
right in aggregate, but the fix is a balance edit across content.gd and so is
the user's call.

check.sh clean, 357 tests, SMOKE PASS (18 assertions), all four diagnostics
green.

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

docs/NETCODE.md

@@ -257,6 +257,27 @@ Pickup shares `BTN_INTERACT` with the dungeon portal. Loot wins when both are in
 reach, but only on a tick where something was actually taken, so a full bag
 cannot leave a player standing on the portal unable to use it.
 
+## Upgrades change what a shot is, and none of it is client-side
+
+A player's damage, fire rate, bullet speed, shot count and every rider
+(splitting, poison, erasure) come from `PlayerStats`, rebuilt on the server from
+the upgrade ids the character holds. The client builds its own copy for the
+choice screen's summary, and that copy decides nothing — it exists so the panel
+can show real numbers instead of promises.
+
+Three things fall out of it worth writing down:
+
+- **The riders live on the bullet, not on the shooter.** A shot already in
+  flight keeps what it was fired with, so taking Poison mid-flight cannot reach
+  back and poison it. They stay zero on a replica, which never resolves a hit
+  and has no use for them.
+- **Choosing an upgrade is intent, checked three ways.** The client sends an
+  index; the server checks a choice is owed, that the index names one of the
+  three options *it* put on the table, and that the player is standing at the
+  hub NPC. The index selects from a list the client did not write.
+- **The offer is server state.** Rolled once, stored on the character, and
+  persisted — so closing the screen is not a reroll, and neither is a crash.
+
 ## No contact damage
 
 Nothing hurts you by touching it. Every threat is a bullet you can see and
@@ -294,6 +315,8 @@ transition, not a combat mechanic.
 | Leaving the hub early after death | `RESPAWN_LOCKOUT_TICKS`, server-side |
 | Item action repeated by a held key | edge-triggered against `prev_buttons` / `prev_slot` |
 | Inventory slot index out of range | `SimPlayer.take_slot` answers "nothing" |
+| Upgrade choice made anywhere but the hub NPC | `SimWorld.at_upgrade_npc`, server-side position |
+| Upgrade index outside the server's own offer | `CharacterStore.take_upgrade` refuses |
 
 The respawn lockout is worth calling out: the HUD disables its button for the
 same three seconds, but that is presentation. A client that ignores its own UI