fix(agent): pending-inbound queue + replay (#121) and thread-as-container working-ensure

[unforced]

Two coherent parts plus a supporting finding. Central, subtle code — heavily commented, especially the turn_count and pending-replay logic. No version bump.

Part A — pending-inbound queue + replay-on-register (fixes #121; agent-side, NO vault change)

The bug. In daemon.ts contextFor.emit, an inbound for a channel with no live programmatic agent (programmatic.hasChannel(channel) === false — a just-defined agent not yet instantiated, or a brief channel/agent desync) fell through to a 0-subscriber SSE/MCP push and was silently dropped, while /api/vault/inbound still returned 200. The vault trigger acks 200 as done (stamps <trigger>_rendered_at) and never retries → permanent loss (0 turns, 0 threads, no reply).

The fix. The daemon now OWNS an inbound it can't yet process:

• ProgrammaticAgentRegistry gains a per-channel pending-inbound buffer (FIFO, capped at PENDING_INBOUND_CAP = 50; past the cap the oldest is evicted with a loud log — bounded loss beats unbounded growth, and the durable inbound notes still exist in the vault), gated by an expectedChannels set.
• New registry API: expectChannel / unexpectChannel / queuePending(channel,msg) → "queued"|"unknown" / pendingCount / isExpected.
• register() drains the channel's pending buffer through the normal enqueue path (FIFO, arrival order) once the agent is live, then clears the expected mark (the live byChannel index is the truth).
• emit (daemon.ts) wires it: no live agent → queuePending; "queued" returns (200, owned); "unknown" falls through to the existing push (a genuine telegram/bridge channel still works). The handler always 200s — a 4xx/5xx would strand the trigger in _pending_at.
• buildInstantiateDeps.ensureChannel calls expectChannel before bringing the channel live (closing the desync window); deregister calls unexpectChannel.

In-memory is acceptable for v1: a daemon restart loses pending, but the durable inbound notes exist and loadAll + the 60s def-poll reconverge.

Part B — thread-as-container (definition → thread → message)

The #agent/thread note is now a CONTAINER ensured when the agent starts processing a message, then UPDATED by the turn — not a post-turn by-product.

API change — phase: "start" | "end" on ThreadRecord (transport.ts) / ThreadNote (registry.ts):

• drain writes a working-ensure (status: "working", input shown, NO reply) with phase: "start" BEFORE deliver().
• The existing post-turn recordThread writes the final record with phase: "end" (the default when absent — back-compat).

turn_count counted EXACTLY ONCE (on end), never double-counted across start+end — in VaultTransport.writeThread:

• phase: "start" → turn_count = prior (single) / 0 (multi); last_turn_at NOT advanced; started_at preserved/initialized.
• phase: "end" → single increments prior + 1 (unless sameTurn, the outbound-failure re-record); multi = 1; last_turn_at advanced.
• Trace: turn 1 start→0, end→1; turn 2 start→1 (unchanged), end→2; ok→error re-record stays 1.

The start-ensure and end-record share the per-turn threadId, so single-threaded UPSERTS its deterministic note and multi-threaded targets the SAME per-fire note (no duplicate). buildThreadSummaryBody handles the working state (no fake reply).

Latent-bug fix: buildWriteThread (daemon.ts) previously dropped threadId and sameTurn — so through the real daemon path a multi-threaded re-record would mint a duplicate note and single-threaded sameTurn would double-count. It now forwards threadId + sameTurn + phase.

Message ↔ thread linkage: the OUTBOUND #agent/message note is stamped with metadata.thread (the per-turn thread id), threaded WriteOutbound → reply() via meta.thread. For multi-threaded this IS the per-fire note leaf. Deferred: INBOUND-note stamping (those notes are written externally before the turn knows its thread); single-threaded outbound→note-by-stable-path. Not blocking.

Part C — desync finding (supporting)

agent-defs.ts loadAll re-instantiates every enabled def on boot AND the 60s poll (instantiate always calls ensureChannel + setupAndRegister; register() is idempotent-replace). So any channel/agent desync self-heals within one poll cycle; the reload webhook is the fast path. Part A's expect+replay closes the residual window (inbound landing between channel-live and agent-register). No code change needed beyond Part A's expectChannel wiring.

Tests & gate

bun run test (typecheck + bun test ./src) = 995 pass, 0 fail.

• Part A: inbound for an expected-but-unregistered channel is QUEUED (not dropped) and the handler 200s; register() drains FIFO + runs turns in order; cap enforced; unknown channel logs + 200s (no crash); channel-move clears old marks/buffer.
• Part B: working-ensure write happens BEFORE deliver (gated-turn assertion); status working→ok/error; turn_count no-double-count at the transport (single 1→2, multi 0→1, sameTurn stays 1); start+end target the same note; working body has no fake reply; outbound stamped with thread id.
• Regression: existing thread/drain/outbound-failure tests (incl. FIX-1 re-record + turn_count) updated to be phase-aware via an ends()/starts() filter — they still verify their substance with the added working-ensure.

Review

Independent reviewer pass: LGTM with nits, no critical issues. Both substantive nits fixed in the second commit (channel-move expected/pending leak + working-body wording); the turn_count invariant trace was independently verified.