D288 M-155: ran the GE_D288 probe, result inconclusive -- needs frame-gating

Ran the M-152 next-step probe (GE_D288=1 GE_PCDUMP=560-745:5, backgrounded,
25s bare -level_20 boot). Two problems surfaced with the probe itself, not
the underlying bug: it fires 116k times in ~1500-2000 frames (the
bbox_frac>0.15 threshold catches ordinary near-camera geometry throughout
the whole run, not just the reported ~562-741 window), and the target
color signature (83,62,44) never appears in the log. No GE_PCDUMP PPM
output was produced either, so no visual cross-check was available.
Confidence unchanged from M-152; this is a probe-refinement finding, not
a root-cause finding. Recorded the concrete next step (frame-gate GE_D288
on num_dls the way GE_D236RM already does) in the D288 entry.

Also caught and documented a real tooling gotcha: a backgrounded
ge007.x86_64.exe launch from this Bash tool doesn't reliably die to
`pkill -f` (process shows as bare `ge007.x86_64` in ps, no .exe suffix) --
a stray instance ran ~90s past its intended capture window before being
caught via `taskkill //F //IM ge007.x86_64.exe`. Added to porting-notes.md
so the next session uses taskkill from the start.

findings-index.csv regen was a no-op (no new Dxx label).

docs/porting-notes.md

@@ -1382,6 +1382,16 @@ made mutually acceptable (dual validation / one-time migration).
   TMP=... TEMP=...` to a real writable per-session directory (the Claude
   Code scratchpad path works well) before `ninja`/`build-pc.sh`, not just any
   Windows-looking path string.
+- **A backgrounded `ge007.x86_64.exe` launch from this Bash tool does not
+  reliably die to `pkill -f ge007.x86_64.exe`** (M-155, D288 session): the
+  process appears in `ps aux` as bare `ge007.x86_64`, no `.exe` suffix, so
+  the `-f` pattern match on the full name silently fails and the game
+  window (and its log-writing) keeps running well past the intended
+  `sleep N` capture window — one session let a stray instance run ~90s
+  longer than intended before it was caught. Use `taskkill //F //IM
+  ge007.x86_64.exe` instead to reliably terminate it from this shell, and
+  `ps aux | grep -i ge007` to confirm before moving on — don't trust a
+  `kill`/`pkill` exit code alone.
 - **A crash fault address of `0xffffffffffffffff` on x86-64 usually means a
   non-canonical #GP from a garbage-high-bits pointer (bits 63:48 not a sign
   extension of bit 47), not a computed `-1` sentinel** (cross-validated