BT410 5.3.104a: the duck's driver is unfound -- recorded, not invented

The squat clips and states exist end to end, but the binary's DuckRequest
handler only lights the cockpit lamp (duckState -> the gauge databinding),
and no decompiled code arms states 1/2/3 or calls SetDuckedCollisionTemplate.
The mechanization lives in the un-decompiled master perf. Noted in
MECH2.NOTES.md so nobody re-derives the dead end.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

restoration/source410/BT/MECH2.NOTES.md

@@ -369,3 +369,22 @@ mech2 header said "airborne/jump-jet" — recorded so nobody re-litigates it.
 mode 3/4 — a MECHDMG increment; nothing sets the mode in real play yet), and
 IntegrateMotion's remaining pieces (orientation/velocity integration, the
 dead-reckon fold, turn-in-place arming).
+
+## The duck: clips found, driver unfound (2026-08-03)
+
+5.3.103 put the squat clips in slots 3 (`squ`) and 2 (`sqd`) with
+`squatCapable`, and the machines have always carried the matching states —
+2 plays the squat-down and holds at 1 (Advance returns 0: the crouch hold),
+3 stands back up. But **nothing arms them**. The binary's `DuckRequest`
+handler (@0049fa00, the RIO crouch button, id 0x1a) is one line —
+`duckState = 1` — and BT411's search found no reader of `duckState` in any
+decompiled code: its consumer is the cockpit DATABINDING
+(`oneOfSeveralPixInt(...DuckState)` — the duck lamp), and the mech reset is
+the only other writer. `SetDuckedCollisionTemplate` (@004ac04c) exists to
+shrink the collision cylinder, caller likewise unfound (likely the
+un-decompiled master perf).
+
+So the crouch's mechanization lives in code nobody has decompiled yet.
+Writing an arming path would be invention; the states stay dormant until
+the master-perf disasm names their driver. Recorded so the next reader
+doesn't burn a session rediscovering this.