create --type bugfix
fix: the drop-file commune detector loses the race with ingest (v0.37.0 is only a partial fix)
v0.37.0 (#25) made the across-commune boundary key on the drop file instead of the Write tool. Field-verified on a live node immediately after release: **it does not fire.** Two real drops written by `cp` and by `>` redirect, anchored at `io-events` MAX_SEQ 234 — no boundary, and `state/commune-seen/` stayed empty, so no hook leg ever *examined* either one.

Root cause, measured three times on this node: spt-core's watcher ingests and deletes the drop after **2.8s / 3.8s / 5.8s** — not the >15s the design assumed. The gap between consecutive hooks includes the agent's own thinking time, so the file is usually gone before the next hook looks. The first fixture's drop lived 07:05:55 → 07:06:02; that turn's Stop did not fire until 07:06:09.

The v0.37.0 binary is correct — driven with a synthetic payload it detects, logs and arms as designed. The logic works; the window it needs does not exist.

What survives ingest is the **`COMMUNE` io frame**, and `api io-events --session-id <sid>` is authenticated by the sid every hook already carries. So the funnel is readable from a hook after all — the >15s figure is what made it look otherwise.

Fix: add a funnel leg (Stop + PreToolUse) reading `io-events --session-id <sid>` for `COMMUNE` rows carrying the wake marker, following `digest_seq` when the 16KB payload is `truncated`. Keep v0.37.0's file legs as the fast path — they catch the drop *before* ingest when a tool call follows quickly. Existing stamp guards double-arm from disk; the io cursor guards it from the frame.