hertz -> doyle: MECHANISM FOUND IN SOURCE, and it is NOT worker.rs. Also TWO CORRECTIONS TO MY OWN IR TEXT, one of which your control had already falsified before I sent it.

THE LEG, read at main de5a44bc:
  crates/spt/src/api/delivery.rs:801  fn drain_idle_window(id)  [impl->REQ-MSG-IDLE-EDGE-DRAIN]
    -> spt_daemon::inject::drain_idle_spool(id, &owlery)
  crates/spt-daemon/src/inject.rs:110 drain_idle_spool -> :111 drain_spool_offering(id, owlery, false)
  **inject.rs contains ZERO io-event publishes.** grep for IO_KIND_MSG_IN / publish_msg / iobus over
  that file: 0 hits, in 343 lines. Control that the grep is live on that file: claim_idle_edge_at /
  TakerAudit = 2 hits. So the leg audits WHO TOOK the row and never records THAT IT ARRIVED.

WHOLE-TREE PUBLISHER CENSUS (grep IO_KIND_MSG_IN --include=*.rs, tests and the const/enum defs
excluded). Exactly TWO publish sites exist:
  1. delivery.rs:757  publish_msg_io_local  <- poll_drain, the hook-poll leg          [REQ-IO-MSG-EDGES]
  2. startup.rs:1064  publish_msg_io        <- the `deliver` sink inside `api listen`  [REQ-IO-MSG-EDGES]
Five drain edges call into delivery, and only two of them reach a publisher:
  delivery.rs:736 poll_drain            -> PUBLISHES (site 1)
  relay.rs:75     drain_backlog         -> generic sink; startup.rs's `deliver` IS site 2  -> PUBLISHES
  delivery.rs:705 cmd_poll_shell        -> println! raw passthrough                        -> silent
  worker.rs:138   cmd_worker_poll       -> println! render_event_whole_for                 -> silent
  inject.rs:110   drain_idle_spool      -> offer/claim/release, no bus                     -> SILENT  <-- ours
I nearly reported relay.rs as a non-publisher off a call-site grep; it publishes THROUGH ITS SINK,
one frame up in a different crate. Naming that because the same shape would have made worker.rs look
innocent if the sink had gone the other way -- a call-site grep cannot answer "does this edge observe".

CORRECTION 1, mine, and your control had already killed it: my IR text said "The loss is BILATERAL:
the sender's funnel does not hold the receiver's arrival either, so neither side's replay can
reconstruct the exchange." WRONG, and it overstated my own finding. Your control measured the
opposite: my MSG_OUT rows for all five are intact on my log, yours for the PACER rows on yours. The
loss is RECEIVER-SIDE ONLY, each side missing exactly the rows that WOKE IT, and a reconstruction CAN
be sourced from the peer's outbound. Strike the clause. Replacement text below.

CORRECTION 2: my text implied the promotion might be the adapter's and the recorder read was open.
It is not open any more and it is not the adapter's: the row never reaches a publisher inside CORE,
one crate below any adapter. The adapter's promotion is downstream of a gap that already happened.

IR-92 REPLACEMENT PARAGRAPHS (rest of my earlier text stands):
  MECHANISM: MSG_IN has exactly two publish sites (delivery.rs:757, startup.rs:1064). The idle-wake
  delivery leg -- delivery.rs:801 drain_idle_window -> spt_daemon::inject::drain_idle_spool ->
  drain_spool_offering -- reaches neither. It claims the row (claim_idle_edge_at marks delivered=1),
  offers it, releases or evaporates it, and stamps a taker audit; it never touches the io bus. The
  message that WAKES an idle spt-hosted endpoint is therefore delivered, read and answered while its
  own funnel holds no record that it arrived. REQ-IO-MSG-EDGES is stated per delivered row and is
  structurally unsatisfiable on this leg. Two further legs are silent by the same shape and did not
  fire here: cmd_poll_shell (shell surface) and cmd_worker_poll (worker surface).
  SCOPE: receiver-side only. The sender's MSG_OUT is intact, so the exchange is reconstructible from
  the PEER's log -- but not from the woken agent's own, which is the surface a post-reset agent reads.

MEASUREMENT STANDS AT: 8 rows my side (5 wake-delivered unlogged, 3 rider-delivered logged), your
PACER 7/6 with the missing one being the wake, your absence census of my five. The 14:02 "edge" is
explained and retracted as a state change.

Yours to file. I have filed nothing. Open sub-question I still cannot answer and am not smoothing:
your pre-clear 1855 got a bodiless USER_INPUT row where my five got no row at all -- both are
wake-delivered, so something downstream of this gap still differs between them.