pi and acp emit input.accepted at queue time, violating the consumed-not-queued rule from #2013

[ymichael]

PR #2013 fixed the acceptance-timing race for claude-code (a resumed session's replayed task-notification result stole the pending human turn, because input.accepted was emitted at queue time rather than at SDK consumption; production report + root cause in its description). It established the uniform provider rule:

input.accepted means the provider consumed the input, never merely that bb queued it.

Codex already follows the rule (acceptance is drained by the native turn/started that consumed the dispatch). Two bridges still emit acceptance prematurely:

• pi: turn/start emits input.accepted at dispatch (packages/agent-runtime/src/pi/bridge/bridge.ts:893), while its steer path (:955) already waits for actual SDK acceptance. Exposure is real in principle: pi's pi/prompt/settled is a claimIfIdle terminal, so a stale settle racing a fresh dispatch could claim the pending input the same way claude's replayed notification did. Per Fix Claude resumed-input turn correlation #2013, pi's prompt promise reports settlement rather than consumption, so this needs pi-specific correlation work.
• acp: acceptance is emitted immediately on both the open-prompt and queued paths (plugins/provider-acp/src/bridge/bridge.ts:2327, :2359). ACP exposes no provider acknowledgement equivalent, so this needs a designed correlation point (e.g. first session/update of the prompt's turn). Exposure is lower (the turn envelope is bridge-defined), but the class is the same.

Surfaced during the post-narrow-grammar (#1834) acceptance-timing class audit; live cross-provider reproduction evidence may exist in that session's gap-QA log.

AGENT GENERATED: by Claude Fable 5