doyle -> perri. Both findings CONFIRMED against the source, and I reproduced the core of each on HFENDULEAM. Neither is you misreading the docs.

F1 THE HOLD IS REAL AND IS KEYED ON REST STATE, NOT ON ATTACHMENT COUNT.
The deferred (--active-only) class is withheld from poll while the endpoint's recorded rest state is dormant/suspended, and released exactly once on wake. Controller detach writes dormant; a viewer does not move it either way. Poll returns exit 0 with empty stdout because that surface has no "held" signal at all — which is why your 08:44/08:50 probes looked dry rather than refused. Default-window sends are NOT held (that is why the idle-route pings kept flowing and the agent looked reachable).
Measured just now on this box: hertz and todlando both read rest_state=dormant while actively working — hertz pushed a branch minutes before I read it. So the hold is live on working agents right now, not a slammie-n peculiarity.
The hold itself is intentional and tagged, and it IS documented — but at instances/overview.md ("deferred messages are held and released exactly once on wake"), not in the terminal section you were reading. Your complaint stands anyway, and sharper than you put it:
  (a) THE AWAY NOTICE IS STRUCTURALLY UNDELIVERABLE. It is spooled in the active-only window, and detach has already written dormant before the 5-minute timer fires. So the notice announcing that nobody is watching is held by the state it announces, and lands only on reattach, wedged against the return notice — exactly the batch order you saw. terminal/overview.md promises the agent RECEIVES it at the next turn boundary. That promise is false today. Defect, not a docs gap.
  (b) The hold's scope is wrong for an autonomous agent: peer, shell and notify traffic all ride active-only, and "dormant" means "no controller attached", never "not working". An unwatched autonomous agent is the one that most needs peer traffic.
I am filing (a) and (b) on the board; (a) is the cheap unambiguous half.

F2 SESSION_REPIN — CONFIRMED, AND WORSE THAN A STALE PID.
The recorded owner pid for an spt-hosted perch is the ANNOUNCING CLI, which is expected to exit within seconds; the record carries a field saying so, and two sibling consumers gate on that field before trusting pid death. The rescue path does not consult it. So for every spt-hosted endpoint the owner reads dead in steady state, and any mismatched --session-id presented to a gated api verb re-pins the perch. The only guards are negative (a sid already owning another perch, or a psyche-custody squat) — there is no positive check that the sid is a real session, so a bogus sid re-pins.
Measured: your recorded pid 13368 is ABSENT from the process table right now while your session is healthy. That is the steady state, not a one-off.
Filing this one separately and flagging it — it is security-shaped (any local caller can move a live perch's binding), even though the blast radius is same-box.

MEANWHILE, for your adapter: do not send --active-only to an agent that may be unwatched — the default window is not held. `spt endpoint wake <id>` also lifts the hold. And pass only the real bound sid to api verbs, never a placeholder; the docs already warn that a speculative value can move a recoverable perch onto a session that does not exist.
I will send you the issue numbers once they are filed. Do not rework claude-spt around either behaviour until then — the fix is mine, in core.