fix(omp): bound the post-agent_end completion gate

[joeshull]

Downstream feature: true
Downstream rationale: Bounds the OMP post-agent_end completion gate so a stalled or unreachable get_state cannot hold a finished turn in running forever; authored in this fork, and also proposed upstream into the getpaseo#3371 feature branch.

Merge order: this cannot target internal/main until #29 lands, because it builds on the subagent wait that #29 imports. CI only runs on pull requests targeting main or internal/main, so while this is stacked on omp-idle-gate-3371 no CI runs on it. Once #29 merges, retarget this to internal/main; its three commits then apply unchanged, and the downstream-feature exception above needs one non-author human approval of the current head.

Refs getpaseo#3654. The first two commits shown in the branch are @jasonhnd's, imported by #29; this pull request's own diff is the three commits after them.

Problem

After an assistant-bearing agent_end, OmpAgentSession.completeTurnAfterProviderIdle() polled runtimeSession.getState() every 10 ms waiting for isStreaming === false && isCompacting === false, swallowed every error, and had no deadline. If OMP reported a stale state or the state RPC kept failing, the turn showed as running until the user cancelled — and startTurn throws while a turn is active, so the session was wedged for new prompts. The only signal was a logger.debug line, and the daemon runs at info level, so nothing surfaced at all.

The loop has never been modified since it shipped in getpaseo#2067; the two tests that pin the unbounded wait came in that same commit. getpaseo#2261 and getpaseo#2282 both fixed reaching the gate and explicitly kept it as-is ("the change does not synthesize idle or add a timeout"). getpaseo#3371 adds a third reason to wait inside it. Upstream can1357/oh-my-pi#6916 is a field occurrence of the symptom — a session held running for 25m44s after the final answer and only cleared on a forced cancel — still open, waiting on RPC evidence the host never emitted.

While reproducing this in the provider harness I also found the gate could complete a turn twice: every agent_end opened another concurrent loop, and two loops that both observed idle each called completeTurn.

Change

Budgets. OmpProviderIdleScheduler.waitForRetry() takes { attempt, consecutiveFailures, elapsedMs, isCompacting, isWaitingOnSubagents } and returns {retry: true} | {retry: false, reason}. The default scheduler backs off 10 ms → 1 s and gives up after 3 consecutive get_state rejections, after 60 s of monotonic wall clock, or after 10 minutes if OMP reports compaction. Wall clock rather than a retry count is deliberate: each get_state carries the JSONL-RPC request timeout, so counting attempts would let a slow-but-answering state path stretch the wait to tens of minutes. Compaction gets its own budget because the gate waits for isCompacting to clear and compacting a large context is a model call that routinely outlasts 60 s.

The subagent wait (getpaseo#3371). A get_subagents reply listing running children is positive evidence OMP is working, and a fan-out has no bounded length, so the wait budget does not apply while that evidence is current. It resumes the moment get_subagents stops answering — which is the stuck-parent risk that closed getpaseo#2245: an index still holding children it can no longer confirm no longer holds the turn open forever. The get_state failure budget applies throughout.

Structured failure. On abandon the turn fails with omp_provider_idle_timeout or omp_provider_state_unavailable. A gate that never observed any state reports state_unavailable whichever budget ran out, because a hanging get_state burns the wait budget before three rejections can land. The diagnostic carries the last observed isStreaming/isCompacting, the last RPC error, and whether subagents were still reported running. turn_failed already carries code and diagnostic (agent-sdk-types.ts), so there is no packages/protocol change and nothing to gate on server_info.features. The turn state is cleared, so recovery is an ordinary prompt.

One gate per turn. Gates are keyed on the turn ID, with a shared key for autonomous cycles (which carry no turn ID and poll like any other gate). The gate holds the terminal payload and the newest agent_end overwrites it — unless that would discard an error the gate already holds, since the fallback payload is a single assistant message.

Ownership. Ownership is re-checked before completing and before failing, not only at the top of each poll. Both sites sit after two awaits, and a get_state carries the 30 s RPC timeout, so a cancel-then-reprompt could otherwise let a stale gate fail the cancelled turn and clear the new one's turn ID.

Terminalize on stall. A stall leaves OMP's state unknown, so tool calls and subagents still marked running are cancelled — otherwise they spin in the UI with no turn left to finish them.

The safety property from the issue is preserved: no ordinary turn_completed while OMP reports streaming, compacting, or running children, and a healthy state response before the budget still completes exactly once.

Tests

Sixteen new tests in packages/server/src/server/agent/providers/omp/agent.test.ts (on top of getpaseo#3371's), each written before its production change and watched fail — except the two that drive createOmpProviderIdleScheduler() directly, whose pre-change failure was an import error rather than a behavioral one:

• exactly one completion when OMP repeats agent_end, foreground and autonomous
• turn fails on wait-budget expiry and on repeated get_state failures, with the right code each time
• wait-budget expiry whose last check failed keeps both the state and the error in the diagnostic
• a gate that never observed a state reports state_unavailable
• newest agent_end error wins over the first snapshot, and an earlier error survives a later error-free cycle
• a stale gate does not fail or clear a turn that started after it was abandoned
• the session reports observed compaction, elapsed time, and the subagent wait to the scheduler
• the subagent wait stops being trusted once get_subagents stops answering
• in-flight tool calls are cancelled when the gate gives up
• a new prompt is accepted after a stalled turn fails
• the default scheduler's budget decisions, including compaction and subagent waits

getpaseo#3371's tests and the two pre-existing tests that assert the gate stays active while OMP is busy or unreachable are unchanged and still pass.

QA

• npx vitest run packages/server/src/server/agent/providers/omp — 19 files, 143 tests pass
• npm run typecheck — clean
• npm run lint on the changed files — 0 warnings, 0 errors
• npm run format:check — clean

Not exercised against a live OMP process; the harness reproduces every failure mode deterministically. This change surfaces the stall with the last state and RPC error but does not persist raw child RPC frames, which is the evidence oh-my-pi#6916 is still waiting on.