fix(sdk): keep an attached chat session alive across a socket drop, and resume it in order

[probepark]

Scoped replacement for the chat-daemon reconnect portion of the closed #4021. Six commits, 9 files, one subsystem: an attached chat session must survive losing its socket, and must resume in order, exactly once.

This is the surface the #4021 reviewer red-teamed twice. Both of their blockers are fixed here, with the integration tests they asked for.

The defects

1. The reconnect budget only covered the initial dial (021399101, 59f5ae2df)
The SDK host drops any session whose client has not ponged within HEARTBEAT_TTL_MS (20 s). SdkClient defaults to 3 attempts at 25 ms base — a 175 ms total budget — so any stall long enough for the host to reap the session was unrecoverable. #4012 fixed this for ACP via ACP_SESSION_RECONNECT; the chat daemon's long-lived attached-session clients still inherited the one-shot default. The constant is hoisted to src/sdk/session-reconnect.ts so the bus layer can reach it without importing the ACP layer, and attach() now dials on it. The per-request broker client keeps the one-shot defaults deliberately — it closes in its own finally.

attach() is a protected chat-daemon lifecycle declaration, so CHAT_DAEMON_GENERATIONS is bumped: an owner still running the old code gives up reconnecting after 175 ms and permanently loses its attachment.

2. An established attachment still died silently (98d194668)
Raising the budget fixed the initial dial and nothing else. ChatDaemonRuntime installed client.onFrame() only inside attach(), and SdkClient never opens a replacement socket on its own — it retires the closed incarnation and re-dials on the next connect/request. A chat attachment is purely passive, so a transient drop silently ended delivery for good, and any later command-triggered reconnect resumed from nowhere. Chat notifications simply stopped.

The attachment now keeps its socket dialed through client.onReconnect — the same mechanism sdk/acp/adapter.ts already relies on — and replays from its own cursor, fenced exactly as attach() already fences: this session id, this endpoint generation. A superseded attachment is disposed, never resurrected.

3. The resume raced live frames, reordering and duplicating them (a7ee32a5f)
Resuming started the replay asynchronously while the live onFrame subscription stayed open, so two producers wrote into the same queue with no barrier. Worse, the cursor guard only advanced on seq > cursor and never rejected seq <= cursor, so the replay republished a frame the live socket had already delivered.

Reproduction: deliver seq 1 → drop the socket → record seq 2 during the outage → accept the replacement → deliver live seq 3 before the replay answers. Required [1, 2, 3]; actual [1, 3, 2, 3].

Ingress is now fenced for the duration of the resume — live frames arriving in the hello→replay window are held and drained in sequence order behind the replayed events — and any frame at or below the cursor is dropped instead of republished. The fence cannot deadlock: an unanswered replay leaves the cursor intact so the next reconnect re-issues it, which is the pre-existing failure path.

4. A unit test burned the real 41.75 s budget (6cccc9441)
sdk-acp-provider-reconnect dialed a dead endpoint with the production budget and timed out at 5 s — failing on clean origin/dev ever since #4012 grew it. Injecting a one-shot client keeps the assertion about the typed rejection and drops the run from 41.9 s to 96 ms.

Verification

Every regression test is load-bearing, proven by restoring only chat-daemon-runtime.ts from origin/dev and re-running:

chat-daemon-session-reconnect    7 pass / 0 fail   →  1 pass / 6 fail without the fix

The four cases the reviewer required, each failing without the fix:

case	without	with
live seq3 before replay answers	[seq1, seq3, seq2, seq3]	[seq1, seq2, seq3]
replayed frame at/below cursor	duplicate published	dropped
stop while replay pending	hang (20 s timeout)	returns, publishes nothing held
supersession while replay pending	held frame replayed onto the new attachment	discarded

The full published array is asserted, not a set or a length.

+ control-frames + daemon-control + acp reconnect + provider reconnect   199 pass / 0 fail
bun --cwd=packages/coding-agent run check                                exit 0
telegram-daemon-generation-guard                                         v43 required generation bump verified

packages/bridge-client is untouched: changing reconnect semantics there would hit every consumer, including one-shot request clients.

Relationship to #4021

#4021 bundled twelve unrelated defects into 53 files and was closed with the instruction to open fresh, scoped PRs. This is the second of those, after #4031 (ACP turn lifecycle). Remaining groups — broker/host lifecycle, gc/disk retention, tool diagnostics — follow as separate PRs.

[probepark]

Self-review: REQUEST_CHANGES on my own PR. A red-team pass showed the barrier's failure path silently loses events, and the justification I wrote into the code is wrong. Verified in source.

Blocker: a failed replay discards held frames, then the cursor is dragged over the gap

On a replay failure the barrier returns, revokes itself, and drops held[]. My comment justified that two ways; both are false on a live socket:

"the next reconnect re-issues it" — there is no next reconnect. #replayAttachment is driven only by client.onReconnect (chat-daemon-runtime.ts:565-566), which fires from SdkClient.#acceptHello when a NEW connectionId arrives. If the socket never dropped, there is no hello and no retry. #reviveTransport calls connect(), which is a no-op on a live socket, so the reconcile tick does not rescue it either.

"the cursor stands" — it stands for exactly one frame. The next live frame has seq > cursor, so :815 (attached.cursor.seq = seq) drags the cursor straight over the discarded gap, and those events are unrecoverable even if a reconnect happened later.

So the barrier converts a recoverable ordering problem into permanent silent loss — the same class of defect as the reordering it was written to fix, which is worse because nothing reports it.

Related: the hold buffer drops the OLDEST frame

:811-812:

held.push({ seq, frame });
if (held.length > REPLAY_BARRIER_LIMIT) held.shift();   // REPLAY_BARRIER_LIMIT = 1_024

Bounding the buffer is right; shift() is not. Under a long outage with heavy traffic it evicts the oldest held frame — the one nearest the cursor, i.e. the one that must be delivered next for the sequence to stay contiguous. Overflow should either fail the barrier loudly and force a full reattach, or drop from the newest end and reset the cursor to the last contiguous seq. Silently discarding the frame the ordering depends on defeats the barrier.

What the fix has to be

1. A failed replay must not advance the cursor past unreplayed sequences. Either keep the held frames until a replay succeeds, or reset the cursor to the last contiguous delivered seq so a later reconnect genuinely re-issues them.
2. Give the barrier a retry path that does not depend on a new hello, since the failure mode being handled occurs on a live socket.
3. Fix the overflow policy so the buffer cannot evict the next-needed frame, and surface the overflow rather than hiding it.

Not merging until those are in, with regressions covering: replay rejects on a live socket → no cursor advance and no lost events; overflow → contiguity preserved or a loud reattach. The earlier reconnect-budget and resume commits in this PR stand; this is specifically the barrier's failure path.

[probepark]

Blocker fixed in 6ad3e4b4b: a failed replay now retries on the live socket with bounded backoff while the hold stays intact, and exhaustion resets the cursor to the last contiguously-delivered seq so a later replay genuinely re-issues the gap. Overflow no longer evicts the next-needed frame — it fails the barrier loudly and reattaches through the endpoint-generation fence. Regressions: no event lost on a rejected live-socket replay (full array asserted), cursor never crosses an un-replayed gap, overflow reattach. 197 pass / 0 fail across the reconnect+control suites; 7 pass/3 fail without src; manifest regenerated (v43 verified).

[probepark]

Local codex-pro review gate: APPROVE, no blockers, after 677451a29 (rebased onto current dev).

Conceding a retention gap left the cursor below the conceded range, so the next reconnect re-requested events the host had provably discarded and the attachment could never move past them; a legitimate replay whose retained slice was empty was also treated as a failure. The cursor now advances to the end of a conceded gap — the honest statement that those events are unrecoverable — and delivery resumes after them.

204 pass / 0 fail across reconnect + control-frames + daemon-control; 9 pass / 8 fail with packages/coding-agent/src stashed; check exit 0; generation guard v43 required generation bump verified.