task-44: the assert reaches evdev, and the 1444 run is explained

KEY_WAKEUP lands on event4 at the same timestamp as the hardware edge, so the
existing XF86WakeUp bind can already see it. arm generates its own edge, which
means re-arm-on-interrupt feeds itself - that was the 1444 events, not the
sensor. wakeup_enable takes enable/disable, not 1.

docs/tasks/44-fingerprint-fpc1020.md

@@ -173,11 +173,39 @@ signal, not the sensor. Any future instrument must arm exactly once per window;
 `fp-window.py` on the phone does, and prints per-second deltas so a real
 detection can be seen to *cluster* rather than spread.
 
-**Still open, and it is the only thing left: does a finger raise an edge.** A
-60 s armed window recorded 0 IRQs, but **no finger was confirmed on the reader
-during it**, so that run is not evidence about detection in either direction —
-do not cite it as one. The rig is ready: TA resident, line idle-low, baseline
-a hard zero, so a single confirmed touch settles it.
+**The chain reaches userspace.** With the sensor armed and idle-low, an assert
+was caught end to end:
+
+    EDGE  at t+94.73s  +1  total=169  line=high
+    EVDEV at t+94.73s  code=143 value=1   <-- KEY_WAKEUP
+    EVDEV at t+94.73s  code=143 value=0   <-- KEY_WAKEUP
+
+Sensor → IRQ 168 → driver → `KEY_WAKEUP` on `/dev/input/event4`, same
+timestamp. That is the evdev path `hyprland.lua`'s existing `XF86WakeUp` bind
+already listens on, so the routing question is answered. Across ~120 s of
+armed-but-untouched windows the count never moved; every assert has come in a
+window where a touch was being attempted. **Attribution to a finger still rests
+on the human confirming the touch** — the rig cannot tell a finger from any
+other cause, so say "an assert" until someone says "I touched it then".
+
+**`wakeup_enable` and `device_prepare` take the vendor's `enable`/`disable`
+strings, not `0`/`1`** — a `1` returns `EINVAL` (`wakeup_enable_store`). The
+driver gates the key on it, so **`KEY_WAKEUP` reaches evdev only after
+`echo enable > wakeup_enable`**. Anything productionising this must set it.
+
+### Why the 1444-event run happened — solved, and it constrains the design
+
+**`arm` (cmd 3) generates its own edge, +1, measured.** So a handler that
+re-arms on every interrupt feeds itself: arm → edge → handler → arm → edge,
+without end. The 1444 events were the instrument, not the sensor and not a
+finger.
+
+That is a design constraint, not a footnote. The sensor asserts **once per
+arm** and then latches high until the TA clears it, so a usable input *must*
+re-arm after every event — and a naive re-arm is exactly the storm. Whatever
+lands has to suppress the arm's own edge (ignore the edge that follows an arm
+within a few ms, or ask the TA for finger state instead of re-arming blind).
+Do not ship a re-arm loop that has not solved this.
 
 ## Piece 2 — biometrics, which is a TrustZone question