D288: frame-gate the GE_D288 probe, re-run, still inconclusive

Gated GE_D288 to num_dls 550-755 (the reported bug window, same pattern
GE_D236RM already uses) and raised the bbox threshold from 0.15 to 0.5.
Volume dropped 116k -> 28,883, but that's still not the isolated signal
-- traced the remaining noise to a bad assumption in the probe itself:
bbox_frac from a raw x/w divide is meaningless once any_behind_camera=1
(w<0 or near-zero), which is exactly why the surrounding D233 code already
defers to GL's own clipper for that case rather than trusting the divide.
Restricting to any_behind_camera=0 (2,128 hits) still found no match for
the target color (83,62,44); the persistent hits across the window look
like static level geometry, not the transient bug triangle.

Working theory: the bare -level_20 boot's scripted intro camera may not
reach the same state the original visual bug report came from -- the same
"deterministic boot flag != deterministic camera path" pattern this
session's D236 passes independently hit on a different level. Recorded a
revised next-step list in findings.md; a live human repro is now more
promising than further headless probing of this specific approach.

No src/game changes. findings-index.csv regen was a no-op.

docs/dev/findings.md

@@ -11075,7 +11075,9 @@ if that's recorded anywhere in the D280 write-up above.
 - **Next, concrete:** gate the probe to the actual bug window before re-running — extend `GE_D288` with a `num_dls` (frame counter) check bounding it to roughly 560-745 (same pattern `GE_D236RM` already uses for its own frame gating, `gfx_pc.cpp` ~line 1648), and/or tighten the bbox threshold well above the apparent ~0.15 "normal" baseline this run established. Confirm the correct `GE_PCDUMP` output-directory env var (see `docs/dev/GE-ENV-PROBES.md`'s `GE_PCDUMP` row) before relying on visual frame dumps again.
 - **Environment note, reinforcing the existing one:** the launched `ge007.x86_64.exe` process does **not** reliably die with `pkill -f ge007.x86_64.exe` from this Bash tool (process shows in `ps aux` as bare `ge007.x86_64`, no `.exe` suffix) — a stray instance ran ~90s longer than intended this session before being caught via `taskkill //F //IM ge007.x86_64.exe`. Use `taskkill //F //IM ge007.x86_64.exe` (not `pkill`) to reliably terminate a backgrounded launch from this shell.
 
-**Status (from §F table):** OPEN — visually confirmed and precisely bounded (frames ~562-741 of a bare `-level_20` boot); M-152 narrowed to two live candidates (fast3d backface-cull NaN leak, or the D106/D271 portal-BFS family) via static review; M-155's probe run was inconclusive (probe not frame-gated, fires too broadly to isolate the signal) — root cause still not identified. A frame-gated `GE_D288` re-run is the next concrete step. Promoted from the long-parked `GRAPHICS-BACKLOG.md` D171 entry with real evidence.
+**M-155 follow-up (same session): frame-gated re-run also inconclusive — bbox_frac is not a meaningful signal when `any_behind_camera=1`.** Gated `GE_D288` to `num_dls` 550-755 (matching the reported window) and raised the threshold to `bbox_frac > 0.5`, then re-ran the same 25s bare `-level_20` boot. Volume dropped from 116k to 28,883 hits — still far too many to be the single reported triangle. Root cause of the remaining noise: for `any_behind_camera=1` triangles (a vertex behind the camera plane, `w<0`), the perspective-divide math `x/w` this probe uses to estimate screen coverage is **not meaningful in the first place** — dividing by a near-zero or negative `w` produces arbitrarily large/nonsensical "bbox_frac" values for perfectly ordinary near-camera geometry, which is exactly why the surrounding code already defers to GL's own clipper for these triangles rather than trusting a raw NDC divide (see the D233 comment just above this block). This isn't evidence of the bug; it's the probe's own math breaking down in a case it was never valid for. Restricting to `any_behind_camera=0` (2,128 of the 28,883 hits) still found **no match for the target color** `(83,62,44)`; the largest/most persistent hits (`(82,94,89)`, `(70,70,70)`, repeating identically across every sampled frame in the window) look like static level geometry, not the transient grow/shrink/vanish triangle. **Working theory, unconfirmed:** the bare `-level_20` boot's scripted intro camera may not reach the same in-game state the visual bug report was captured from — the same "deterministic boot flag ≠ deterministic/representative camera path" caveat this session's D236 passes (10/11) independently ran into on a different level. **Confidence: unchanged, LOW-MEDIUM; probe volume is now sane but still hasn't isolated the signal.** **Next, concrete, revised:** (1) restrict the probe to `any_behind_camera==0` only (the `w<0` case needs a different, GL-clip-aware approach or should be dropped entirely as a false lead); (2) get a real `GE_PCDUMP` PPM capture working (confirm the output-dir env var) to visually confirm which `num_dls`/frame the boot's camera is actually at when the bug is visible, rather than assuming the frame-range label transfers directly to `num_dls`; (3) if headless deterministic-boot probing keeps missing it, this may need a live human repro with `GE_PCDUMP`/F12 at the moment the triangle is visible, same as D290's falsifier plan.
+
+**Status (from §F table):** OPEN — visually confirmed and precisely bounded (frames ~562-741 of a bare `-level_20` boot); M-152 narrowed to two live candidates (fast3d backface-cull NaN leak, or the D106/D271 portal-BFS family) via static review; two M-155 probe runs (ungated, then frame-gated) were both inconclusive — the `any_behind_camera=1` case's bbox math is a false lead, and the `any_behind_camera=0` subset found no match for the target color. Root cause still not identified; a live human repro is now the more promising next step over further headless probing. Promoted from the long-parked `GRAPHICS-BACKLOG.md` D171 entry with real evidence.
 
 ## D289 — Dam: a crash in the computer room, not reproducible on a second attempt (M-141, Steam Deck user playtest).