Document the weapon-fire/pick-range investigation, paused per user

Records tonight's finding before stopping this thread: the user correctly
pushed back on an oversimplification (the renderer isn't a purely passive
wire tap -- the protocol has a real synchronous pick-query shape, sect_pixel/
sect_vector, where the board runs its own Moller-Trumbore ray-triangle test
and replies with range+identity). Checked directly against the REAL firmware
(not just the reference software renderer's notes):

- sect_pixel/sect_vector never appear in this capture -- unused by this build.
- Action 0x23 (the notes' fire/pick candidate) gets no reply from the real
  firmware either (checked via the h_reply hook, which fires on ANY
  firmware-issued reply) -- but its payload doesn't match the documented
  FLYK format at all (no screen coords; a counter-tagged discharge-event
  shape instead), and its wire context (list_remove + zone-color + a
  PSFX-shaped 0x1d) reads as a weapon-discharge notification with visual
  consequences, not a pick query.

Net: open question, not resolved. BT4.10/MUNGA's real pick/range mechanism
(if board-side at all) is not yet identified. Paused per the user rather
than continue an open-ended search without a specific pointer.

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

emulator/firmware-decomp/IG-SHADING-MODEL.md

@@ -247,7 +247,7 @@ No wire-level investigation done yet. BT411's `gauges-hud.md` /
 draw pass? a different coordinate space/orthographic projection? a distinct
 wire action type?) before searching the firmware blind.
 
-### 6d. Weapon-fire rendering — not observed, cause NOT YET INVESTIGATED
+### 6d. Weapon-fire rendering / board-side pick-range mechanism — PARTIALLY INVESTIGATED, PAUSED
 Per BT411 `rendering.md` §"Weapon beams": beams are ordinary TUBE geometry
 (`ermlaser.bgf`), muzzle-anchored every frame — i.e. on the wire this should
 look like ordinary create/list_add/draw_scene traffic for a thin, elongated
@@ -255,7 +255,46 @@ object, NOT a special ray-trace primitive. Per `combat-damage.md`, the
 original game's fire/target-lock mechanism is fully reconstructed and working
 in BT411's port, so a live session showing no fire is more likely an input/
 session-state gap (RIO fire button not reaching this DOSBox session) than a
-missing render path — check that before assuming a rendering gap.
+missing render path.
+
+**User's counter-point (2026-07-21), correcting an oversimplification above:**
+the renderer is NOT a purely passive tap in the strict protocol sense — there
+IS a real query/response shape in the wire protocol (VELOCIRENDER_PROTOCOL.md
+`vr_sect_pixel`(4)/`vr_sect_vector`(5): synchronous, blocking, the board runs a
+REAL Möller–Trumbore ray-triangle test over its own live scene and replies
+with an instance handle — "the exact range to the pixel in the center of the
+target and what that pixel is a part of"). Whether the SHIPPED BT4.10/MUNGA
+build actually uses this path (vs. computing it host-side, as BT411's own
+`HudSimulation`/pick-ray reconstruction does) was the open question.
+
+**Investigated, using this pipeline's unique capability (running the REAL
+firmware, not a reimplementation):**
+- `sect_pixel`(4)/`sect_vector`(5) never appear on this capture's wire at all
+  (0 occurrences) — this build doesn't use the 1994-enum pick-query actions.
+- Action `0x23` (the notes' "fire/pick" candidate) DOES appear (23 times), and
+  checked directly against the real firmware's OWN reply mechanism (`h_reply`
+  hook, which fires on ANY firmware-issued reply regardless of action): NO
+  reply follows `0x23` in this build either — consistent with the old
+  fire-and-forget finding, now confirmed against the actual firmware code
+  rather than just the software reimplementation.
+- BUT the `0x23` payload itself does NOT match the documented FLYK format
+  (`[u:f][v:f][host ptr][-1]`, screen coords) — this build's payload is
+  `[1][incrementing event ID | 0x30000000][0]`, no screen coordinates. Wire
+  context around it (`0x23`×2 → `list_remove`×2 → `0x1b`×2 → a 264-byte
+  `0x1d`, matching the documented PSFX/particle-burst branch ≥160B) reads
+  like a WEAPON-DISCHARGE NOTIFICATION with visual consequences (a projectile
+  resolving + effect spawn), NOT a board-side "what's under the crosshair"
+  query. So `0x23` in BT4.10/MUNGA is very likely NOT the same mechanism the
+  1994-era FLYK notes describe under the same action number.
+
+**Net conclusion: open.** Either this build's real pick/range mechanism lives
+under a still-unidentified action, or BT4.10/MUNGA moved this computation
+entirely host-side (matching BT411's own architecture) and `0x23` (whatever
+it really is) is unrelated to targeting. Paused here per the user
+(2026-07-21) rather than open a broader search without a specific pointer —
+resume by identifying what wire traffic accompanies a KNOWN weapon fire in a
+fresh, targeted capture (fire once, deliberately, with minimal other action
+noise) rather than mining an existing capture for a guessed action number.
 
 ### 6e. Cockpit cage — intermittent, NOT YET CROSS-CHECKED
 See `emulator/render-bridge/COCKPIT-CAGE-NOTES.md` (the OTHER renderer's