D219 M-157 correction: measured G_LIGHTING for glass2.c sparks, theory doesn't hold up

Went back and actually tested the G_LIGHTING hypothesis from the
previous commit instead of leaving it as an untested code-reading
inference. Two things prompted this: (1) noticed a code comment near
the existing GE_D172 probe documenting a live result never written up
in findings.md -- "G_LIGHTING is ruled out (5000/5000 samples off)" for
explosion.c's particles specifically, meaning the sibling case this
session's theory leaned on was already empirically disproven, not
merely unconfirmed; (2) that's exactly the kind of unchecked assumption
this session's own rule-2 taxonomy work was written to prevent.

Added GE_D157 (gfx_pc.cpp, gfx_sp_vertex, env-gated, cached getenv):
logs geometry_mode/LIGHTING + resulting shaded RGB whenever a vertex's
raw color bytes match one of glass2.c's g_BulletSparkColors[] entries.
Re-ran the identical Bunker1 repro that produced the magenta/green/cyan
screenshots -- only 2 hits, both LIGHTING=off, both unaffected white,
no hit at all for the pale-yellow value the door-spark path should
produce. Reading: G_LIGHTING likely isn't the mechanism here either
(consistent with the sibling case), though the probe may simply not be
catching the real spark vertices yet (exact-byte-match is fragile).

Corrected the D219 finding to flag the "cross-validates M-110" framing
from the previous commit as superseded, not delete it -- the reasoning
trail (including the mistake) stays visible so a future session doesn't
repeat it. Root cause of the visually-confirmed rainbow bug remains
open; next steps revised to a texture-identity-keyed probe variant.

Added GE_D157 to GE-ENV-PROBES.md. No src/game changes. findings-index
regen was a no-op.

port/fast3d/gfx_pc.cpp

@@ -1501,6 +1501,36 @@ static void gfx_sp_vertex(size_t n_vertices, size_t dest_index, const Vtx* verti
             d->color.b = vcn->b;
         }
 
+#ifdef PORT
+        /* D157 diag (temporary, session 2026-09-16/17): does bullet_spark_render
+         * (glass2.c) actually draw with G_LIGHTING on? The M-110 mechanism
+         * (this vertex's v.cn[]/n.n[] union reinterpretation above) was
+         * already ruled out for explosion.c's particles (5000/5000 samples
+         * measured LIGHTING=off, see the D219 comment a few hundred lines
+         * below) -- don't assume it holds for glass2.c's bullet sparks
+         * without measuring. Key on the ORIGINAL authored bytes
+         * (v->v.cn[], readable regardless of which branch fired above,
+         * since n.n[]/cn[] are the same union storage) matching one of
+         * glass2.c's g_BulletSparkColors[] entries exactly. */
+        static int ge_d157 = -1;
+        if (ge_d157 < 0) ge_d157 = getenv("GE_D157") != NULL;
+        if (ge_d157) {
+            static const uint8_t known[][4] = {
+                {0xFF,0xFF,0xFF,0xFF}, {0xFF,0xFF,0xC8,0xFF}, {0xFF,0x00,0x00,0xFF},
+            };
+            for (const auto& k : known) {
+                if (v->v.cn[0] == k[0] && v->v.cn[1] == k[1] && v->v.cn[2] == k[2] && v->v.cn[3] == k[3]) {
+                    sysLogPrintf(LOG_NOTE,
+                        "D157: bulletspark-color-match cn=(%d,%d,%d,%d) geometry_mode=%08x LIGHTING=%s -> shaded=(%d,%d,%d)",
+                        v->v.cn[0], v->v.cn[1], v->v.cn[2], v->v.cn[3], rsp.geometry_mode,
+                        (rsp.geometry_mode & G_LIGHTING) ? "ON" : "off",
+                        (int)d->color.r, (int)d->color.g, (int)d->color.b);
+                    break;
+                }
+            }
+        }
+#endif
+
         d->u = U;
         d->v = V;