re: add a hunting pilot; withdraw the "10 of 116 records are dynamic" result

The user asked for an actively hunting pilot, since a player who kills nothing
cannot trigger an event-gated wave and both previous runs used the survival
pilot.

pilot.py gains SYLPH_HUNT=1. The substantive change is which contacts ENGAGE may
shoot: it previously skipped every "hard" target -- "turrets and hulls are not
the objective" -- and stood off 2500 units from turrets, on the assumption that
an e007 Turret is an AA mount on a capital ship. It is a craft, one of the main
enemy types of the first six missions, and at 100 HP the cheapest kill on the
field. Under SYLPH_HUNT it is a target and the keep-out drops to 600. The run
confirms the pilot engages: steady ENGAGE, fire=1, committed to an
e010_ADAN_Attacker_S at ~2.2 km, hull and escorted asset untouched over 160 s.

Withdrawn: "only 10 of 116 records ever changed a byte in 170 s". This run
measured 41-56 records changing in every 10 s tick. The old figure does not
reproduce.

I cannot say why, because I changed two variables at once -- the record bound
(fixed 0x200 to bounded-by-next-record) and the pilot (survival to hunting).
Either explains it. That is a design error, and the honest outcome is a
retraction without a replacement explanation rather than a story that fits.
The conclusion it had supported is unaffected: the roster identity now rests on
the exact 10-of-10 unit-composition match measured independently.

Still open, and explicitly not concluded: the pilot's own entity scan shows ADAN
drifting 147 -> 129 -> 142, and the late rise has the shape of an arrival, but
the sample-to-sample swing is +/-10, the same size as the effect. AGENT.md warns
that polling faster than the guest updates manufactures a curve out of noise, so
no wave conclusion is drawn. The run probably did not kill anything either
(fc=0, asset at 100%), so it does not test the event-gated model. A stable
per-record liveness field and a working kill counter are both needed first;
REMAINING OB at 0xbdb59668 still does not read as a counter.

docs/re/BACKLOG.md

@@ -332,8 +332,11 @@ search cannot find a *schedule*.
   moves in one and not the other.
 * 🔴 **Diffing inside the 116 records did not find the arrival flag**
   (2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte
-  in 170 s — more support for the pre-allocated roster — and STRONGER than
-  first written: the "turrets don't move" hedge was withdrawn after the user
+  in 170 s — 🔴 **the "10 of 116 dynamic" figure is WITHDRAWN** — a hunting
+  run measured 41–56 records changing per tick; I had changed two variables at
+  once (record bound and pilot) so the discrepancy is unattributed. The roster
+  identity is unaffected: it now rests on the 10/10 unit-composition match.
+  Earlier note, kept for history: the "turrets don't move" hedge was withdrawn after the user
   pointed out that early-mission "Turret" is a craft type, which the data
   confirms (`UN_e007_ADAN_Turret` flies under `AI_ADAN_CraftSquadron_*`, never
   `AI_Structure`). Lesson: check a unit's `AIID`, not its English name. No field transitions in groups of 3 at the