Avoid double-counting tool-delegate turn tokens

When a turn uses continue_delegate, the earlier tool-delegate block consumes the queue and doToolSpawn() already persists continuationChainTokens including this turn's usage. Because that leaves dispatchToolDelegates() with nothing to consume, toolDelegateDispatchResult is unset here and this fallback reloads the already-updated activeSessionEntry while adding turnTokens again. In sessions with continuation cost caps, every tool-delegate turn is charged twice and can prematurely block valid continuation chains.

Useful? React with 👍 / 👎.

Thanks for catching this — the cross-flow double-count is real, but the bug substrate is at line 2913, not the ?? fallback at 2955.

After cohort byte-walk (3 retraction rounds + 4 independent walks) we landed on:

The substrate: Block A (lines 2147-2613, bracket-signal path) and Block B (lines 2909-2930, consume-and-dispatch path) are sequential top-level if blocks. Both gated on continuationFeatureEnabled && sessionKey, both can fire same turn (the only co-fire-blocking gate is wasSilentContinuation at 2902, which is the silent-continuation early-return).

When both fire:

1. Block A's bracket persist at line 2240 sets bracketTokensAccumulated = true and writes T_prev + T_turn to activeSessionEntry.continuationChainTokens via persists at 2397/2539
2. Block A's tool-delegate path at 2797 may also persist (covered by the bracketAlreadyAccumulated guard at line 2669-2675 — that guard works correctly within Block A)
3. Control falls through to Block B at line 2909
4. Line 2913: loadContinuationChainState(activeSessionEntry, turnTokens) reads the now-mutated entry → returns (T_prev + T_turn) + turnTokens = T_prev + 2·T_turn. Double-count.
5. dispatchToolDelegates runs with the doubled budget; toolDelegateDispatchResult.chainState carries the doubled value
6. Persist at 2956 writes the doubled value via nextState = toolDelegateDispatchResult?.chainState

The ?? fallback at 2954 is dead code when Block B's dispatch ran (because toolDelegateDispatchResult IS assigned at 2914 inside the same if (continuationFeatureEnabled && sessionKey) gate). It only matters when the queue is empty AND bracket already fired — which is a narrower window than the substantive bug at 2913.

Fix shape (mirrors the existing 2669-2675 bracketAlreadyAccumulated guard):

const turnTokens = bracketTokensAccumulated ? 0 : (usage?.input ?? 0) + (usage?.output ?? 0);

Branch with the fix + regression tests: fix/p1-paired-chainstate-persistence (commit 5abf294757). Includes 3 new tests in state.test.ts covering double-count-without-fix, fix-prevents-double-count, and cost-cap-budget-correct-after-co-fire.

The cohort byte-walk that landed this:

• 🩸 Block A/B asymmetric-guard via bracketTokensAccumulated
• 🌫 four-anchor-byte pin (2240/2669/2797/2913) + 7-step cross-flow trace
• 🌊 fourth-walker co-fire confirmation
• final cosign by all four princes

Persist hedge-fired delegate chain state

When a delayed continue_delegate matures while the session is otherwise quiet, this hedge callback is the only code path that dispatches it, but it discards the dispatchToolDelegates() result. dispatchToolDelegates() only returns the advanced chainState; the durable writeback happens later in agent-runner.ts for the normal awaited path, so hedge-fired accepted delegates do not update continuationChainCount/tokens and later quiet delayed hops can bypass the max-chain/cost guards.

Useful? React with 👍 / 👎.

Confirmed at the byte — your diagnosis is correct.

The hedge callback void dispatchToolDelegates(...).catch(...) discarded the returned Promise<{ dispatched, rejected, chainState }>, so delegates dispatched via the hedge timer never had their advanced chain state written back to activeSessionEntry.continuationChainTokens / continuationChainCount. Subsequent quiet delayed hops loaded the stale-pre-hedge state and could legitimately bypass maxChainLength / cost-cap enforcement — exactly the substrate you named.

Fix landed in commit 55601064c6 on branch fix/p1-paired-chainstate-persistence:

• New optional persistChainState?: (state: ChainState) => void | Promise<void> callback threaded through armHedgeTimer + dispatchToolDelegates params, symmetric with the existing loadFreshChainState pattern (caller-supplied because the lazy-runtime module intentionally doesn't have access to the durable triple-write persistContinuationChainState in the agent-runner closure)
• setTimeout callback becomes async, awaits dispatchToolDelegates(...), persists when result.dispatched > 0 (skips spurious persists when queue drained between arm and fire)
• Closure-wiring at agent-runner.ts:2926 binds the callback to the local triple-write persistContinuationChainState helper (durable: sessionEntry + sessionStore + disk via updateSessionStore)
• Try/catch swap from .catch() to async/await preserves error-path identical: rearm-on-failure still fires via armHedgeTimer(sessionKey, Date.now() + HEDGE_DISPATCH_FAILURE_RETRY_MS, params)

Test coverage added in src/auto-reply/continuation/delegate-dispatch.test.ts (3 new tests): persist-via-callback after hedge dispatch, skip-on-zero-dispatched (validates the result.dispatched > 0 guard), max-chain budget enforcement after hedge persists advanced state.

Per-seam rationale-artifact at artifacts/seam-delegate-dispatch-103-rationale.md on the same branch documents anchor bytes + ordering-race considerations for archaeology.

Branch will land via separate PR after PR #604 admin-squash-merges to canonical (per workorder template §2 strict-shape, cohort-cosigned). Crediting your diagnosis explicitly in the rationale-artifact.

Useful signal — thank you.

Add traceparent to agent RPC schema before sending it

When a continuation-backed subagent return carries a traceparent, this spread adds it to the agent gateway request, but AgentParamsSchema is additionalProperties: false and does not define traceparent (I also checked the server request type). In that scenario the gateway rejects the completion/wake request as invalid params, so traced continuation returns can fail instead of waking or notifying the requester; either add the field to the protocol/server plumbing or keep it out of the RPC params.

Useful? React with 👍 / 👎.