switchroom 0.19.17 → 0.19.18

package/telegram-plugin/hooks/secret-guard-pretool.mjs

@@ -10,15 +10,75 @@
  *   Output: exit 0 + empty stdout → allow.
  *           exit 0 + JSON on stdout with `decision: "block"` + `reason` → block.
  *
- * Performance note (closes #472 finding #7):
- *   Earlier versions forked `switchroom vault list` + `switchroom vault get`
- *   per key — each fork paid ~785ms of CLI cold-start cost. With N vault
- *   keys × every tool call, that compounded to seconds of overhead per turn.
+ * Performance note (#472 finding #7, then #3543):
+ *   Generation 1 forked `switchroom vault list` + `switchroom vault get` per
+ *   key — each fork paid ~785ms of CLI cold-start. Seconds per turn.
  *
- *   This version connects directly to the running vault-broker daemon via
- *   its NDJSON unix socket protocol (see src/vault/broker/protocol.ts) and
- *   issues sequential list+get requests over a single connection. Sub-10ms
- *   total even with several keys, vs 800ms × (1 + N) before.
+ *   Generation 2 spoke the broker's NDJSON unix-socket protocol directly
+ *   (see src/vault/broker/protocol.ts) but issued `list` + N `get` requests
+ *   SEQUENTIALLY over one connection. Its header claimed "sub-10ms total
+ *   even with several keys". That claim was wrong by ~15×: measured
+ *   in-container on 2026-07-25 the hook cost ~145ms per tool call, of which
+ *   ~132ms was 1 + N sequential round trips at ~19ms each (#3543). A false
+ *   perf claim in a header comment is how that stayed invisible; the numbers
+ *   below are measured, not assumed.
+ *
+ *   Generation 3 (this one) keeps the same two logical phases but fans the
+ *   `get` phase out CONCURRENTLY, one request per connection, so the CLIENT
+ *   issues ~2 round trips' worth of requests instead of 1 + N serialized
+ *   ones.
+ *
+ *   ⚠ READ THIS BEFORE QUOTING A NUMBER. Client concurrency is NOT the
+ *   whole cost, and an earlier draft of this header claimed "~2 round trips
+ *   regardless of key count" — which was false against the real broker, for
+ *   the same reason generation 2's "sub-10ms" claim was false. Whenever the
+ *   request carries a token (which is ALWAYS, in an agent container:
+ *   readVaultToken() below always finds `.vault-token`), the broker runs
+ *   `validateGrant` per request — `list` at src/vault/broker/server.ts:1105
+ *   and every `get` at :1284 — and that awaits a `bcryptjs.compare`
+ *   (src/vault/grants.ts, BCRYPT_COST=10). bcryptjs is pure JS and BLOCKS
+ *   the broker's single event loop: measured 2026-07-25, one compare is
+ *   ~57ms on the fleet host and 8 "concurrent" compares took 459ms — fully
+ *   serialized. The broker is shared by every agent, so N keys cost the
+ *   broker (N+1) × compare of serialized CPU that no amount of client
+ *   fan-out can shorten.
+ *
+ *   That is why #3574 also added an exact positive-result memo for the
+ *   bcrypt comparison in src/vault/grants.ts (revocation/expiry/key_allow
+ *   are still read live from SQLite on every call — only the immutable
+ *   "does this secret hash to this digest" fact is memoized). With it, the
+ *   per-request broker CPU collapses to a Map lookup after the first
+ *   request and the fan-out delivers what it promises. Without it, this
+ *   hook's real cost is dominated by broker CPU, not by round trips.
+ *
+ *   The failure mode when broker CPU DOES saturate is a security
+ *   degradation, not a hang: on deadline expiry we keep whatever arrived
+ *   and scan a PARTIAL key set, so a secret can be guarded on one tool call
+ *   and unguarded on the next. `warnOnUnreachableGets` below exists so that
+ *   can never happen silently.
+ *
+ *   Why one request per connection rather than pipelining N gets down the
+ *   single connection: the broker dispatches each line to an async handler
+ *   WITHOUT awaiting it (src/vault/broker/server.ts:924), and the `get`
+ *   handler awaits `validateGrant` before replying (server.ts:1284). So
+ *   pipelined responses are not guaranteed to come back in request order,
+ *   and the wire format carries no request id to correlate them by
+ *   (protocol.ts:452 OkEntryResponseSchema is `{ ok, entry }` — no key, no
+ *   id). One request per connection is exactly the shape the protocol
+ *   documents ("one request per connection turn, one response") and needs
+ *   no broker change, so it ships without a broker restart.
+ *
+ *   Why not a TTL cache of vault values: values rotate at runtime through
+ *   the broker's `put` op, and this hook cannot see the vault file to key an
+ *   invalidation off its mtime. A cache would let a freshly-rotated secret
+ *   go unguarded for the cache lifetime — i.e. it would make the guard fail
+ *   open in a case where it currently blocks. Rejected on those grounds.
+ *
+ *   Measured client-side only (fake broker with an ASYNC 19ms service delay,
+ *   6 keys, median of 5): sequential 167.7ms → concurrent ~59ms. Treat this
+ *   as an upper bound on what the fan-out alone buys — a fake broker that
+ *   sleeps does not model the real broker's synchronous bcrypt CPU. See the
+ *   CPU-bound fake-broker test in the sibling test file.
  *
  *   When the broker is unreachable (not running, socket missing, denied)
  *   the hook fails open — same behavior as before. Vault security is owned
@@ -37,6 +97,34 @@ const BROKER_SOCKET =
   ?? join(homedir(), '.switchroom', 'vault-broker.sock')
 const BROKER_TIMEOUT_MS = 1500
 const MIN_VALUE_LENGTH_TO_GUARD = 8
+/**
+ * Max concurrent `get` connections to the broker (#3543). The fan-out is
+ * what makes this hook O(1) round trips instead of O(N), but an unbounded
+ * fan-out on a large vault would open one unix socket per key at once. 32
+ * keeps a typical vault (single digits to low tens of keys) at a single
+ * round trip while capping the worst case at ceil(N/32) rounds.
+ *
+ * ⚠ COUPLING — this hook now needs up to MAX_CONCURRENT_GETS + 1 broker
+ * connections where generation 2 needed exactly ONE. That makes the guard
+ * sensitive to a limit the broker does not currently impose. Verified as of
+ * 2026-07-25: src/vault/broker/server.ts sets no `maxConnections`, no rate
+ * limit and no per-connection mutex, `validateGrant` is a read-only SQLite
+ * lookup, and the socket is bind-mounted into agent containers with no
+ * relay in between — so nothing caps us today.
+ *
+ * But if a future operator adds DoS hardening (server.maxConnections, a
+ * connection rate limiter, an inetd-style relay), the surplus `get`
+ * connections would be refused, `brokerRequest` would resolve null for
+ * those keys, and a tool call carrying one of their secrets would turn
+ * from BLOCK into a silent allow. Reproduced against a 1-connection and a
+ * 3-connection fake broker: old = BLOCK, new = allow.
+ *
+ * The deterministic guard for that is `warnOnUnreachableGets` below — a
+ * connection cap can no longer degrade the guard silently; it always
+ * leaves a line on stderr (captured by bin/run-hook.sh). If you ever cap
+ * broker connections, lower MAX_CONCURRENT_GETS below that cap.
+ */
+const MAX_CONCURRENT_GETS = 32
 
 // ─── Stdin ────────────────────────────────────────────────────────────────
 
@@ -72,92 +160,177 @@ function readVaultToken() {
 // ─── Inline NDJSON broker client ──────────────────────────────────────────
 
 /**
- * Open a connection, run sequential request/response pairs, close.
- * Fails open (returns []) on any error — connection refused, timeout,
- * malformed response, broker locked, etc.
+ * Run exactly ONE request/response turn on a fresh connection, then close.
+ *
+ * This is the unit the broker protocol documents (protocol.ts:8-11 — "one
+ * request per connection turn, one response"). Keeping it to one request per
+ * socket is what makes it safe to run many of these concurrently: no
+ * response-ordering assumption is needed, because each socket only ever
+ * carries one response.
+ *
+ * Never rejects. Resolves `null` on ANY failure — connect refused, socket
+ * error, deadline passed, short read, malformed JSON. Callers treat `null`
+ * as "this key contributed nothing", which is the same fail-open posture the
+ * sequential implementation had.
+ *
+ * @param {object} req  request object to serialize
+ * @param {number} deadline  absolute `Date.now()` ms after which we give up
+ * @returns {Promise<object|null>} parsed response object, or null
  */
-function loadVaultValuesViaBroker() {
+function brokerRequest(req, deadline) {
   return new Promise((resolve) => {
-    const token = readVaultToken()
-    const sock = connect(BROKER_SOCKET)
-    let buf = ''
-    let done = false
-    let pending = null   // { resolve(line) }
+    let settled = false
+    let sock
+    let timer
     const finish = (result) => {
-      if (done) return
-      done = true
-      try { sock.destroy() } catch { /* best-effort */ }
+      if (settled) return
+      settled = true
+      clearTimeout(timer)
+      try { sock?.destroy() } catch { /* best-effort */ }
       resolve(result)
     }
 
-    const timer = setTimeout(() => finish([]), BROKER_TIMEOUT_MS)
+    const remaining = deadline - Date.now()
+    if (remaining <= 0) return finish(null)
+    timer = setTimeout(() => finish(null), remaining)
 
-    sock.on('error', () => finish([]))
-    sock.on('close', () => {
-      clearTimeout(timer)
-      if (!done) finish([])
-    })
+    try {
+      sock = connect(BROKER_SOCKET)
+    } catch {
+      return finish(null)
+    }
 
+    let buf = ''
+    sock.on('error', () => finish(null))
+    // A close before we saw a full line is a failure, not an empty success.
+    sock.on('close', () => finish(null))
     sock.on('data', (chunk) => {
       buf += chunk.toString('utf8')
-      // Split on newlines; emit complete lines through the pending request.
-      let idx
-      while ((idx = buf.indexOf('\n')) >= 0) {
-        const line = buf.slice(0, idx)
-        buf = buf.slice(idx + 1)
-        if (pending) {
-          const p = pending
-          pending = null
-          p.resolve(line)
-        }
-      }
+      const idx = buf.indexOf('\n')
+      if (idx < 0) return
+      const line = buf.slice(0, idx)
+      let parsed
+      try { parsed = JSON.parse(line) } catch { return finish(null) }
+      finish(parsed)
     })
-
-    function send(req) {
-      return new Promise((respond) => {
-        pending = { resolve: respond }
-        sock.write(JSON.stringify(req) + '\n')
-      })
-    }
-
-    sock.on('connect', async () => {
+    sock.on('connect', () => {
       try {
-        // 1. list keys
-        const listReq = token ? { v: 1, op: 'list', token } : { v: 1, op: 'list' }
-        const listLine = await send(listReq)
-        let listRsp
-        try { listRsp = JSON.parse(listLine) } catch { return finish([]) }
-        if (!listRsp || listRsp.ok !== true || !Array.isArray(listRsp.keys)) {
-          // LOCKED / DENIED / etc. — fall through, no values.
-          return finish([])
-        }
-        // 2. fetch each value
-        const values = []
-        for (const k of listRsp.keys) {
-          const getReq = token
-            ? { v: 1, op: 'get', key: k, token }
-            : { v: 1, op: 'get', key: k }
-          const getLine = await send(getReq)
-          let getRsp
-          try { getRsp = JSON.parse(getLine) } catch { continue }
-          if (!getRsp || getRsp.ok !== true || !getRsp.entry) continue
-          // Only string-kind entries are scannable haystack candidates;
-          // binary/files entries can't be substring-matched against a
-          // tool-input string in any meaningful way.
-          if (getRsp.entry.kind === 'string'
-              && typeof getRsp.entry.value === 'string'
-              && getRsp.entry.value.length >= MIN_VALUE_LENGTH_TO_GUARD) {
-            values.push({ key: k, value: getRsp.entry.value })
-          }
-        }
-        finish(values)
+        sock.write(JSON.stringify(req) + '\n')
       } catch {
-        finish([])
+        finish(null)
       }
     })
   })
 }
 
+/**
+ * Map `worker` over `items` with at most `limit` in flight at once.
+ * Preserves input order in the result array.
+ */
+async function mapWithConcurrency(items, limit, worker) {
+  const results = new Array(items.length)
+  let cursor = 0
+  const runners = new Array(Math.min(limit, items.length)).fill(0).map(async () => {
+    for (;;) {
+      const i = cursor++
+      if (i >= items.length) return
+      results[i] = await worker(items[i], i)
+    }
+  })
+  await Promise.all(runners)
+  return results
+}
+
+/**
+ * Load every guardable vault value: one `list` turn, then a CONCURRENT fan-out
+ * of `get` turns (#3543 — this replaces a sequential 1 + N round-trip loop).
+ *
+ * Fail-open contract, unchanged from the sequential version except where
+ * noted:
+ *   - `list` fails / is denied / broker locked  → `[]` (hook allows).
+ *   - an individual `get` fails or is denied    → that key is skipped, the
+ *     remaining keys are still guarded.
+ *   - overall deadline expires                  → whatever HAS been fetched
+ *     is returned and still scanned. The sequential version discarded
+ *     everything on timeout, so this is strictly MORE coverage, never less.
+ */
+async function loadVaultValuesViaBroker() {
+  const deadline = Date.now() + BROKER_TIMEOUT_MS
+  const token = readVaultToken()
+
+  // 1. list keys — one round trip.
+  const listRsp = await brokerRequest(
+    token ? { v: 1, op: 'list', token } : { v: 1, op: 'list' },
+    deadline,
+  )
+  if (!listRsp || listRsp.ok !== true || !Array.isArray(listRsp.keys)) {
+    // LOCKED / DENIED / unreachable / malformed — no values.
+    return []
+  }
+
+  // 2. fetch every value concurrently — one round trip regardless of N
+  //    (up to MAX_CONCURRENT_GETS in flight).
+  //    `unreachable` counts keys whose `get` produced NO response at all
+  //    (connect refused, socket error, deadline) as opposed to a broker
+  //    reply of DENIED/UNKNOWN_KEY. That distinction is the connection-cap
+  //    signal — see the MAX_CONCURRENT_GETS note above.
+  let unreachable = 0
+  const fetched = await mapWithConcurrency(
+    listRsp.keys,
+    MAX_CONCURRENT_GETS,
+    async (k) => {
+      const getRsp = await brokerRequest(
+        token ? { v: 1, op: 'get', key: k, token } : { v: 1, op: 'get', key: k },
+        deadline,
+      )
+      if (getRsp === null) unreachable++
+      if (!getRsp || getRsp.ok !== true || !getRsp.entry) return null
+      // Only string-kind entries are scannable haystack candidates;
+      // binary/files entries can't be substring-matched against a
+      // tool-input string in any meaningful way.
+      if (getRsp.entry.kind === 'string'
+          && typeof getRsp.entry.value === 'string'
+          && getRsp.entry.value.length >= MIN_VALUE_LENGTH_TO_GUARD) {
+        return { key: k, value: getRsp.entry.value }
+      }
+      return null
+    },
+  )
+
+  warnOnUnreachableGets(unreachable, listRsp.keys.length)
+
+  return fetched.filter((v) => v !== null)
+}
+
+/**
+ * Deterministic degradation signal (#3574 review).
+ *
+ * The fan-out silently drops any key whose `get` never came back, and a
+ * dropped key is an UNGUARDED secret — exactly the failure a broker
+ * connection cap would produce. Prose in a comment cannot catch that at
+ * runtime, so emit one line on stderr instead. bin/run-hook.sh captures
+ * hook stderr, so `grep secret-guard ...` answers "is the guard degraded?"
+ * without anyone having to reason about connection budgets.
+ *
+ * One aggregate line, not one per key: bounded output regardless of vault
+ * size. stderr only — stdout is the hook's decision channel and must stay
+ * empty on allow.
+ */
+function warnOnUnreachableGets(unreachable, total) {
+  if (unreachable <= 0) return
+  try {
+    process.stderr.write(
+      `secret-guard-pretool: DEGRADED — ${unreachable}/${total} vault `
+      + `key(s) unresolved within the ${BROKER_TIMEOUT_MS}ms deadline `
+      + `(no broker response: deadline expired, connection refused, or `
+      + `socket error). Those secrets are NOT guarded for this tool call. `
+      + `Likely causes: broker CPU saturation (per-request bcrypt in `
+      + `validateGrant), or a broker connection cap below `
+      + `MAX_CONCURRENT_GETS (currently ${MAX_CONCURRENT_GETS}).\n`,
+    )
+  } catch { /* stderr closed — never let logging change the decision */ }
+}
+
 // ─── Scan ─────────────────────────────────────────────────────────────────
 
 function scanToolInput(toolInput, vaultValues) {

package/telegram-plugin/registry/turns-schema.test.ts

@@ -169,7 +169,7 @@ describe('reapStaleOpenTurns (#2918 mid-session sweep)', () => {
     db.prepare('UPDATE turns SET started_at = ? WHERE turn_key = ?').run(startedAt, turnKey)
   }
 
-  it('stamps an ownerless open row aged past the TTL as restart', () => {
+  it("stamps an ownerless open row aged past the TTL as 'reaped_stale', not 'restart' (#3555)", () => {
     const db = openTurnsDbInMemory()
     const now = 1_000_000_000_000
     recordTurnStart(db, { turnKey: 'dm:dead', chatId: '111' })
@@ -183,7 +183,12 @@ describe('reapStaleOpenTurns (#2918 mid-session sweep)', () => {
     expect(res.reapedTurnKeys).toEqual(['dm:dead'])
     const turn = getTurnByKey(db, 'dm:dead')
     expect(turn?.ended_at).toBe(now)
-    expect(turn?.ended_via).toBe('restart')
+    // #3555: this sweep is NOT a restart. Stamping 'restart' contaminated
+    // every restart statistic derived from the column (1055 rows on one host,
+    // 91.7% clustered at the 15-min reaper TTL, against exactly ONE actual
+    // gateway exit in the same window).
+    expect(turn?.ended_via).toBe('reaped_stale')
+    expect(turn?.ended_via).not.toBe('restart')
     db.close()
   })
 
@@ -233,7 +238,7 @@ describe('reapStaleOpenTurns (#2918 mid-session sweep)', () => {
       now,
     })
     expect(res.reapedTurnKeys).toEqual(['dm:dead'])
-    expect(getTurnByKey(db, 'dm:dead')?.ended_via).toBe('restart')
+    expect(getTurnByKey(db, 'dm:dead')?.ended_via).toBe('reaped_stale')
     expect(getTurnByKey(db, 'dm:live')?.ended_at).toBeNull()
     db.close()
   })

package/telegram-plugin/registry/turns-schema.ts

@@ -17,7 +17,7 @@
  *     thread_id             TEXT              -- nullable: forum topics only
  *     started_at            INTEGER NOT NULL  -- unix ms
  *     ended_at              INTEGER           -- nullable until turn ends
- *     ended_via             TEXT              -- 'stop' | 'sigterm' | 'restart' | 'timeout' | 'unknown'
+ *     ended_via             TEXT              -- 'stop'|'sigterm'|'restart'|'reaped_stale'|'timeout'|'unknown'
  *     last_assistant_msg_id TEXT              -- last outbound message_id in this turn
  *     last_assistant_done   INTEGER           -- 0|1; 1 = stream_reply done=true sent
  *     last_user_msg_id      TEXT              -- inbound message_id that started the turn
@@ -84,7 +84,26 @@ function loadDatabaseClass(): SqliteDatabaseConstructor {
 // Types
 // ---------------------------------------------------------------------------
 
-export type TurnEndedVia = 'stop' | 'sigterm' | 'restart' | 'timeout' | 'unknown'
+/**
+ * How a turn stopped being open.
+ *
+ * `'reaped_stale'` (#3555) is distinct from `'restart'` on purpose. The
+ * mid-session sweep (`reapStaleOpenTurns`) used to stamp `'restart'`, which
+ * made every restart-derived statistic unusable: 1055 rows on one host, 967
+ * of them (91.7%) clustered at 15-19 min — the signature of the 15-min
+ * `MID_SESSION_CARD_REAPER_TTL_MS` on a 5-min sweep, NOT of gateway
+ * restarts (the same window's log holds exactly ONE `[supervise] gateway
+ * exited`). Behaviourally the two are identical — both are clean interrupts,
+ * both are in `INTERRUPTED_VIA`, both map to a `'resume'` — but they are now
+ * separable in the data.
+ */
+export type TurnEndedVia =
+  | 'stop'
+  | 'sigterm'
+  | 'restart'
+  | 'reaped_stale'
+  | 'timeout'
+  | 'unknown'
 
 export interface Turn {
   turn_key: string
@@ -554,7 +573,7 @@ export interface ReapStaleOpenTurnsOpts {
 }
 
 export interface ReapStaleOpenTurnsResult {
-  /** Rows stamped `ended_via='restart'` by this sweep. */
+  /** Rows stamped `ended_via='reaped_stale'` by this sweep (#3555). */
   reaped: number
   /** The turn_keys that were stamped, for logging / card finalization. */
   reapedTurnKeys: string[]
@@ -568,15 +587,19 @@ export interface ReapStaleOpenTurnsResult {
  * leaves its row `ended_at IS NULL`, and its activity card keeps spinning
  * until the NEXT gateway boot (often many hours later). This sweep runs on a
  * periodic timer inside the live gateway and stamps those ownerless open rows
- * `ended_via='restart'` (the same clean-interrupt classification the boot
- * reaper uses for a non-hung orphan) so the stale card can be finalized
- * without waiting for a restart.
+ * so the stale card can be finalized without waiting for a restart.
  *
  * CORRECTNESS: only rows that are BOTH (a) not owned by any live turn
  * (`turn_key ∉ activeTurnKeys`) AND (b) older than `ttlMs` are swept. A
  * healthy in-flight turn — however long it runs — is always in
- * `activeTurnKeys` and is never touched. Never invents a new state; reuses
- * `'restart'` so the existing resume/report policy applies unchanged.
+ * `activeTurnKeys` and is never touched.
+ *
+ * #3555: this used to stamp `'restart'`, borrowing the boot reaper's
+ * classification. That was a lie in the data — nothing here restarted; the
+ * sweep merely gave up on a row after `ttlMs`. It stamps `'reaped_stale'`
+ * now. `'reaped_stale'` is a member of `INTERRUPTED_VIA` and maps to the
+ * same `'resume'` in `selectResumeBuilder`, so the resume/report policy is
+ * byte-for-byte unchanged; only the forensic label differs.
  */
 export function reapStaleOpenTurns(
   db: SqliteDatabase,
@@ -594,7 +617,7 @@ export function reapStaleOpenTurns(
   const stamp = db.prepare(`
     UPDATE turns
     SET ended_at   = ?,
-        ended_via  = 'restart',
+        ended_via  = 'reaped_stale',
         updated_at = ?
     WHERE turn_key = ? AND ended_at IS NULL
   `)
@@ -688,6 +711,7 @@ export function listTurnsForAgent(
 /** ended_via values that mean "this turn did not finish on its own". */
 const INTERRUPTED_VIA: ReadonlySet<TurnEndedVia> = new Set<TurnEndedVia>([
   'restart',
+  'reaped_stale', // #3555 — same clean-interrupt semantics, honest label
   'sigterm',
   'timeout',
   'unknown',
@@ -782,9 +806,13 @@ export function markAnswerRedelivered(
 
 /**
  * Return the single most-recently-started turn IFF it was interrupted
- * (`ended_at IS NULL`, or `ended_via` in {restart, sigterm, timeout,
- * unknown}). Returns null when the latest turn ended cleanly (`'stop'`)
- * or there are no turns at all.
+ * (`ended_at IS NULL`, or `ended_via` in {restart, reaped_stale, sigterm,
+ * timeout, unknown} — i.e. `INTERRUPTED_VIA`). Returns null when the latest
+ * turn ended cleanly (`'stop'`) or there are no turns at all.
+ *
+ * `'reaped_stale'` (#3555) is in that set for the same reason `'restart'` is:
+ * a row the mid-session sweep gave up on was still a turn the user was owed
+ * an answer for. Omitting it would silently drop the resume.
  *
  * This is the resume gate. Keying on the *latest* turn (not "latest
  * interrupted turn anywhere in history") is deliberate: once the agent

package/telegram-plugin/runtime-metrics.ts

@@ -77,6 +77,20 @@ export type RuntimeMetricEvent =
       fallback_kind: 'working' | 'thinking'
       silence_ms: number
     }
+  /**
+   * #3552 — per-turn silence-poke state dropped by the orphan reaper: the turn
+   * behind `key` is provably over (no `activeTurnStartedAt` entry AND no
+   * current turn) yet its state was still armed, so it is disarmed on the poll
+   * tick rather than 300s later at fire time. A healthy fleet trends this
+   * toward zero; a persistent stream of it names a turn-end path that is
+   * failing to call `silencePoke.endTurn`. `silence_ms` is how long the state
+   * had already been orphaned when the reaper caught it.
+   */
+  | {
+      kind: 'silence_poke_orphan_reaped'
+      key: string
+      silence_ms: number
+    }
   /**
    * #2527 — mid-turn liveness floor decision. `decision: 'fire'` when the
    * quiet "still on it" beat was sent; otherwise the machine-readable skip