movement j119 Batch 3+4: pre-register the reversal/dwell and heat-field arms

docs/movement_campaign.md

@@ -803,3 +803,95 @@ which is why every number is inlined above.
 
 The runner writes `<outdir>/session.json` (commit sha, binary sha256, arms,
 panel) so any later job can re-analyze an old session offline, with no arena.
+
+---
+
+## Batch 3 — the reversal/dwell timing of the strafe picker
+
+> **Pre-registration (written and committed BEFORE the battles).** Commit
+> `7311aae` (Task A, the heat field made env-overridable) is the frozen binary.
+> Session `/tmp/ab/j119_b3`. Arms file `tools/ab/arms_movement_b3.txt`, panel
+> `tools/ab/panel_movement.txt`, 6 arms × 15 opponents × 3 runs × 3 rounds = 270
+> battles, conc 6, `--reference strafe`.
+
+**Why this batch.** Batches 1–2 established that the strafe ENGINE wins by
+survival (+0.33…+0.58 wins/run over the shipped `tfil`, incoming hit rate
+−5…−7 pp) and that the RANGE knob is not the lever. The untouched axis is the
+picker itself. The strafe design flips the SIGN of `setForward` (a free
+reversal) and holds a sign for `rand(DWELL_MIN..DWELL_MAX)` ticks, so the dwell
+IS the reversal period — the whole premise of the mover is "when to flip".
+
+**Reference in this batch is `strafe` (current defaults), not `tfil`.** Every
+delta below is (arm − strafe); `tfil` is carried only as the shipped control.
+
+| # | arm | env | what it isolates |
+|---|---|---|---|
+| 1 | `strafe` | `TR_MOVEMENT=strafe` | reference: dwell 6-20, spread 1, reach 144 |
+| 2 | `tfil` | *(none — shipped)* | shipped control / cross-batch calibration |
+| 3 | `fast_flip` | `TR_MOVEMENT=strafe TR_STRAFE_DWELL_MIN=2 TR_STRAFE_DWELL_MAX=8` | reversal every ~5 ticks |
+| 4 | `slow_flip` | `TR_MOVEMENT=strafe TR_STRAFE_DWELL_MIN=12 TR_STRAFE_DWELL_MAX=40` | reversal every ~26 ticks |
+| 5 | `wide_spread` | `TR_MOVEMENT=strafe TR_STRAFE_SPREAD=2 TR_STRAFE_REACH=216` | wider hedge (±2 tiles, 216 px) |
+| 6 | `narrow` | `TR_MOVEMENT=strafe TR_STRAFE_SPREAD=0 TR_STRAFE_REACH=108` | no hedge, short 108 px reach |
+
+**Pre-registered prediction (before the battles):** reversal timing is a real
+mechanism lever; the picker hedge geometry is not. Specifically: (a) `fast_flip`
+will LOWER incoming hit rate vs `strafe` (each heading is exposed for less time)
+and (b) `slow_flip` will RAISE it (a pattern gun gets a longer straight run);
+(c) NEITHER extreme is expected to beat `strafe` on round wins by rule 2
+(a sign-test win with no detectable damage loss), because the win effect is
+bounded by survival that is already high; (d) `wide_spread` and `narrow` should
+not separate from `strafe` (the Batch-2 lesson that picker-shape knobs sit below
+the MDE). If an arm DOES beat `strafe`, the most likely is `fast_flip`, via
+survival. I record this as a falsifiable claim; a wrong prediction is recorded
+as wrong.
+
+*Results appended below after the session.*
+
+---
+
+## Batch 4 — the heat field strength (how strongly strafe treats danger)
+
+> **Pre-registration (written and committed BEFORE the battles).** Same frozen
+> binary (`7311aae`), session `/tmp/ab/j119_b4`, arms file
+> `tools/ab/arms_movement_b4.txt`, 6 arms × 15 opponents × 3 runs × 3 rounds =
+> 270 battles, conc 6, `--reference strafe`.
+
+**Why this batch.** The strafe win is a survival effect, and strafe runs a
+deliberate RETUNE of the shipped heat field: bullet core/aura 20/10 (the core is
+ABOVE the 10-px path threshold, so the bullet itself is the danger), corridor 10
+(== threshold), wall 15/5 (outer ring only), pillar off — vs the shipped field's
+corridor 20 and wall 30/10. The question is whether the retune (or the strength
+of any one source) is what buys the survival. One arm per knob family.
+
+| # | arm | env | what it isolates |
+|---|---|---|---|
+| 1 | `strafe` | `TR_MOVEMENT=strafe` | reference: bullet 20/10, corridor 10, wall 15/5 |
+| 2 | `tfil` | *(none — shipped)* | shipped control |
+| 3 | `bullet_strong` | `TR_MOVEMENT=strafe TR_STRAFE_BULLET_CORE=30 TR_STRAFE_BULLET_AURA=15` | the bullet retune |
+| 4 | `field_strong` | `TR_MOVEMENT=strafe TR_STRAFE_CORRIDOR_HEAT=20 TR_STRAFE_WALL_HOTNESS=30 TR_STRAFE_WALL_RADIANCE=10` | the shipped corridor/wall shape |
+| 5 | `field_off` | `TR_MOVEMENT=strafe TR_STRAFE_CORRIDOR_HEAT=0 TR_STRAFE_WALL_HOTNESS=0` | no corridors, no wall heat |
+| 6 | `wall_tight` | `TR_MOVEMENT=strafe TR_STRAFE_WALL_MARGIN=54 TR_STRAFE_WALL_BIAS=0.7 TR_STRAFE_KAPPA=0.005 TR_STRAFE_WING_MAX=45` | the curved-wing geometry family |
+
+Note on `field_off`: wall hotness is set to 0, NOT the radiance — a radiance of 0
+paints a FLAT `WallHotness` field over the whole arena (the falloff multiplies
+the tile index), which is the opposite of "no walls".
+
+**Pre-registered prediction (before the battles):** the strafe retune is
+load-bearing at the corridor/wall end. Specifically: (a) `field_strong` (the
+shipped saturated corridor/wall shape) will RAISE incoming hit rate and LOSE
+round wins vs `strafe`; (b) `field_off` will be a wash or slightly worse —
+corridors and walls are real threats the picker should see; (c) `bullet_strong`
+will be a wash or slightly worse (a 30 core is above the 25 danger-replan
+threshold, so it over-replans); (d) `wall_tight` will not separate. NET: no arm is
+expected to BEAT `strafe` on round wins, and the current retune should rank at
+or near the top. A wrong prediction is recorded as wrong.
+
+**Task A (this job's separate deliverable).** The shipped `tfil` mover's heat
+shape (`CorridorHeat`/`WallHotness`/`WallRadiance`) was a Nim `const` and could
+not be swept by env; commit `7311aae` makes them env-overridable vars
+(`TR_TFIL_CORRIDOR_HEAT`/`TR_TFIL_WALL_HOTNESS`/`TR_TFIL_WALL_RADIANCE`, shipped
+defaults 20/30/10) and the default path is proven byte-identical by
+`common_libs/tests/test_tfil_commit_env.nim` (30 checks). STRAFE's own heat knobs
+were already env-overridable, which is what this batch sweeps.
+
+*Results appended below after the session.*