task-13: SUID opens, zero reports; irq_skip_pin_config is the next lead

docs/tasks/13-active-edge-squeeze.md

@@ -271,3 +271,48 @@ the SUID (below).
 - TASK-02 lockscreen glance (one plausible policy target for a squeeze).
 - GPT Sol gap prompt (sent 2026-07-18) covers the same gap from the
   external side; this task is the local in-tree half.
+
+## Update 2026-07-26 late — the SUID opens; no reports arrive
+
+Everything up to the last inch works, verified on hardware:
+
+- `touch_gesture` **is served**. libssc discovers the SUID
+  (`6336432434473018525 4921209386564594541`), populates attributes, and
+  reports `available: yes`. Step 2 is answered — yes.
+- The sensor **enables**: "Enabling sensor … in 'single-output' mode /
+  Sensor enable request sent successfully".
+- The rail is up and held (`gpiochip0` line 1, consumer `edge-sense`).
+- The producer listens on the client's `report` signal, the same wiring
+  libssc's proximity sensor uses.
+
+**Zero reports arrive, through many deliberate squeezes.**
+
+### libssc needed a patch to get this far
+
+`libssc-sensor.c` asserted `g_assert_not_reached()` on any stream type that is
+not continuous(0) or on-change(1), aborting the calling process. Gesture
+sensors are **single-output (2)**. Patched: the type is defined, opened with
+the on-change message id (single-output carries no config payload either), and
+the assert is replaced by an `SSC_SENSOR_ERROR_UNAVAILABLE` — a library must
+not abort its caller over a value it read off the device. Packaged as
+`Pixel3Arch/pkgs/libssc-souveraine`, **needs more testing**, and belongs
+upstream (codeberg.org/DylanVanAssche/libssc) since it is not blueline-specific.
+
+### The next thing to look at, from the registry itself
+
+`b1_touch_gesture_0.json`:
+
+```
+irq_num: 125    irq_is_chip_pin: 1    irq_skip_pin_config: 1
+```
+
+`irq_skip_pin_config: 1` tells the SSC driver **not** to configure the
+interrupt pin — it expects it already configured. Nothing on our stack does
+that. The MAX11261 raises IRQ 125 on a chip pin when a squeeze crosses
+threshold; if that pin is unconfigured the DSP never learns a gesture
+happened, which matches the symptom exactly: enable accepted, stream open,
+silence.
+
+So the remaining question is not "is the SUID served" (it is) but **who
+configures IRQ 125**. Downstream that is vendor DT/driver work. Start there,
+not at the client.