Bracket agent-initiated ACP turns so unprompted work renders

[SawyerHood]

What was wrong

When an ACP agent streams work with no session/prompt in flight (the concrete case is OMP's async-job auto-delivery), handleAgentNotification in the provider-acp bridge forwarded every session/update to the translator without opening a turn. ACP has no turn bracket for agent-initiated work, the translator is context-free, and the runtime's delta assembler refuses to let item/stream deltas open a turn, so each unprompted chunk was demoted to a thread-scoped provider/unhandled row. Those rows are hidden unless showUnhandledProviderEvents is on, so the thread simply never answered. Root cause and live repro: https://get-bb.github.io/reports/issues/2122.html.

#2123 (thanks @bradhallett) correctly identified the layer and the shape (a bridge-emitted turn.open, per provider-bridge-protocol turn lifecycle rule 3). It was reviewed REQUEST CHANGES because it tracked the vouched turn in a parallel spontaneousTurnOpen boolean, so the existing readers of activePromptKind kept their old semantics: an agent exit left the turn open forever (thread hangs in Working), permission requests inside the turn were auto-cancelled even in full mode, and the 120 s quiet window buffered the last message and reported "Worked for 2m".

What changed

The bridge folds agent-initiated work into its open-turn mirror
(activePromptKind: "turn" | "compaction" | "agent" | null). A work-kind update
arriving idle opens a turn; a 5 s quiet window ends it; the next turn/start
settles it first; thread/stop interrupts it; an agent exit fails it through the
settling error. Permission requests inside an agent turn are handled like
prompted ones instead of auto-cancelled.

The window measures the agent's silence, and an agent running a tool it already
announced is silent by definition — a build, a test run, or an install sends
nothing until it has a result. So an unsettled tool call counts as activity, not
quiet: the translator answers hasOpenToolCalls(threadId) from its merge cache
(one entry per call, from the tool_call to the terminal tool_call_update),
and the quiet timer re-arms on it exactly as it already does for an unanswered
permission. The turn's other exits still bound it.

The stop reason is chosen where the turn is settled rather than at each call
site. end_turn claims the agent finished, which bb may only assert when the
agent owes the turn nothing; a turn cut short over a running call settles as
cancelled, so the turn and its open rows read interrupted. Without both, the
drain closed a running command as completed with no output, the agent's real
result was dropped by the assembler's settled-key dedup, and the thread flipped
idle mid-work — dispatching the next queued message into a busy agent.

The code lives in packages/provider-bridge-acp (@bb/provider-bridge-acp),
which is where #2325 moved the ACP bridge; the provider-acp plugin is now a
thin declaration layer over it.

How you verified

pnpm exec turbo run test typecheck lint --filter=@bb/provider-bridge-acp --force
— 17 files, 264 tests. Nine tests in bridge.test.ts cover the bracket
end to end against a fake ACP agent: it opens on unprompted work and closes on
quiet, stays shut for non-work updates, settles before the next user turn,
interrupts on thread/stop, fails on an agent exit, and handles a permission
request inside the turn in both full and ask mode. Two more pin the
running-tool cases: the turn stays open across a call that outlasts the quiet
window and the real output lands on its original row, and a user turn arriving
mid-call settles the agent turn and its command row as interrupted rather than
completed. Each of those two fails without its fix and passes with it.

Live in a dev app, using the scripted unprompted ACP agent from the #2122
report registered through the provider-acp customAgents setting. Real omp
16.3.10 and an isolated npm omp 17.4.0 were both driven directly by a
standalone ACP client and never emit session/update once a session/prompt
has settled — omp's ACP prompt handler returns early — so OMP's own async-job
delivery could not be reproduced on this machine and the scripted agent is the
live evidence for the wire shape the issue describes.

The unprompted stream renders as one turn (turn/started 2,
turn/completed 2, provider/unhandled 0, thread idle, closing 5008 ms after
the last update). With the tool left running 9 s, the row settled on the
agent's own result 9035 ms after it opened, carrying SLOW-TOOL-REAL-OUTPUT,
with no turn boundary in between. Sending a message through --mode auto 3 s
into that call settled the agent turn as interrupted with the command row
interrupted and no fabricated output, and the user's turn opened and
completed normally.

Fixes #2122

AGENT GENERATED: by Claude Opus 5

[bradhallett]

Two hardening suggestions before merge, both aimed at the real-omp case rather than the scripted agent:

1. Treat the busy rejection as a signal, not an error. When session/prompt returns the Agent is already processing shape, queue-and-retry with backoff instead of settling the turn failed. The rejection guarantees the prompt never started, so retry is always safe — and this defends bb against any latch-holding agent regardless of what updates it emits, including after omp fixes its side.
2. Classify acp/fs/write as agent-work activity for the vouched-turn bracket. omp emits file writes after a prompt settles but no session/update work kinds in that window (ACP: async-job auto-delivery turns reach clients unbracketed; allowAgentInitiatedTurns never enabled can1357/oh-my-pi#9157 tracks the omission), so this PR's bracket never opens for the busiest real agent. File writes are the agent working.

The 120s quiet-window close is the right fallback either way — keep it.