STRAFE: draw the heat field, real bullet danger, corrected ring comment

Three defects the owner hit as "no heat tiles anymore" under TR_MOVEMENT=strafe.

1. The strafe overlay drew ONLY the tiles on its strafe line, so the computed
   heat field was essentially invisible. It now draws the WHOLE field exactly as
   TFIL does (every non-zero tile, yellow->orange->red ramp by field max, integer
   value label) behind the same debugGraphics flag, with TR_STRAFE_HEAT_GRID=0 to
   hide it. The strafe overlays draw on top, unchanged.

2. STRAFE carried the SHIPPED bullet constants (core 10 / aura 5), so a bullet's
   own heat sat exactly ON PathDangerThreshold (10.0) and a bullet was never
   dangerous on its own in this mover; it only ever bit through its corridor.
   Defaults are now the retune's 20/10, exposed as TR_STRAFE_BULLET_CORE /
   TR_STRAFE_BULLET_AURA.

3. The ring mover's header documented CorridorHeat 5.0 / WallHotness 10.0 while
   the code has always been 10.0 / 15.0. A job read the comment and handed out
   sub-threshold heat values, which emptied the field. The comment now states the
   real values and their actual behaviour; no code values changed.

Also sets strafe's heat defaults to the retune shape (bullet 20/10, corridor 10,
wall 15/5, pillar 0), documented with the reason.

Gate A re-run (j110, offline DrussGT fixture, measure_strafe_gates.nim):
  corrected DEFAULT : 24.6% of picks with ZERO safe tile, mean 11.17 safe
  j108 shipped field: 63.4% / 3.70   (reproduced exactly)
  j108 ring retune  :  8.1% / 18.41  (reproduced exactly)
  bullet isolated   : 11.4% / 17.07
The corrected default beats the shipped field but is WORSE than j108's retune
row: the bullet retune alone costs 8.1 -> 11.4, the corridor/wall retune accounts
for the rest. That is the deliberate price of making a bullet dangerous.

Guards green: test_env_report 24 PASS, test_tfil_commit_env 30 PASS (shipped TFIL
default untouched, byte-for-byte), test_tfil_ring_weights 24 PASS. The three new
knobs are registered in the boot env report so the tree-scan guard stays clean.

common_libs/movements/the_floor_is_lava_ring.nim

@@ -46,24 +46,40 @@
 ##   TR_TFIL_RANGE_HI      default 200.0  band upper edge (px)
 ##   TR_TFIL_RANGE_TEMP    default 0.4    softmax temperature; <= 0 = OFF path
 ##   TR_TFIL_RANGE_K       default 60.0   Gaussian falloff scale (px)
-##   TR_TFIL_CORRIDOR_HEAT default 5.0    lava per corridor-overlapping tile
-##   TR_TFIL_WALL_HOTNESS  default 10.0   peak wall radiance at a wall tile
+##   TR_TFIL_CORRIDOR_HEAT default 10.0   lava per corridor-overlapping tile
+##   TR_TFIL_WALL_HOTNESS  default 15.0   peak wall radiance at a wall tile
 ##   TR_MOVEMENT_LOG=1                    log band/range-class changes (not/tick)
 ## `TR_TFIL_RANGE_TEMP=0` calls plain `rand(candidates.high)` exactly as the
 ## original mover did, so the same binary can serve as the control arm.
 ##
 ## ── Heat-field knobs (the deviation from the original TFIL) ─────────────────
 ## Measured (offline, DrussGT fixtures): corridors are 21.4% and walls 56.4% of
-## the over-threshold set, so they dominate the field. The two constants below
-## are retuned so that NO SINGLE soft source can poison a path on its own:
-##   CorridorHeat = 5.0  — below `PathDangerThreshold` (10.0): one corridor can
-##                         no longer make a path unsafe by itself.
-##   WallHotness  = 10.0 — equals the threshold: the outer two tile rings are no
-##                         longer over-threshold from wall radiance alone.
-## Both are env-overridable (TR_TFIL_CORRIDOR_HEAT / TR_TFIL_WALL_HOTNESS) for
-## an A/B; the defaults are the values measured to unlock the range weighting.
-## WallRadiance, PillarHotness/Radiance, Enemy*/Bullet* and PathDangerThreshold
-## are UNCHANGED from the original mover.
+## the over-threshold set, so they dominate the field. The ACTUAL values in this
+## file (read at module init, `let` block further down) are:  
+##   CorridorHeat = 10.0 — exactly `PathDangerThreshold` (10.0). The safety rule
+##                         is `pathMaxHeat <= PathDangerThreshold`, so a corridor
+##                         tile sitting on a path is still SAFE: a corridor alone
+##                         can no longer make a path unsafe.
+##   WallHotness  = 15.0 — ABOVE the threshold at the OUTERMOST ring only (the
+##                         second ring sits at exactly 10.0, the threshold, and
+##                         is safe), so wall radiance alone CAN poison the outer
+##                         ring but no deeper.
+##   WallRadiance = 5.0  — the falloff that produces the two rings above.
+##   BulletCore/BulletAura = 20.0/10.0 — the bullet's own core is ABOVE the
+##                         threshold, which is what makes an incoming bullet
+##                         dangerous on its own.
+## Both soft knobs are env-overridable (TR_TFIL_CORRIDOR_HEAT /
+## TR_TFIL_WALL_HOTNESS) for an A/B.
+## CHANGED vs the original mover: BulletCore/BulletAura (20/10 here, 10/5 in
+## the original), WallRadiance (5.0 here, 10.0 in the original). UNCHANGED:
+## EnemyCore/EnemyAura and their radii, PillarHotness/PillarRadiance (0/0
+## default) and PathDangerThreshold (10.0).
+##
+## WARNING: an earlier revision of THIS comment claimed CorridorHeat = 5.0 and
+## WallHotness = 10.0. That did NOT match the code — it was a stale copy of an
+## earlier retune PROPOSAL, and a job that read the comment handed out
+## sub-threshold heat values that left the field empty. The code has always been
+## 10.0 / 15.0; the comment now says so.
 
 import std/[math, random, os, strformat]
 from std/strutils import parseFloat, strip  # selective: strutils.fromHex clashes with color.fromHex