fix(opencode): resume queued prompts after interrupt

[rituparna-ui]

Issue for this PR

Closes#40955

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When you submit a message while the agent is busy, the user message is persisted and its caller joins the in-flight run — this is the implicit prompt queue. If you then interrupt the run (ESC ESC), Runner.cancel interrupts the loop fiber and nothing restarts it, so the queued message stays in history unanswered. You have to retype it or recall it from input history.

This PR makes SessionPrompt.cancel check, after the run settles, whether the newest user message ever got an assistant reply — same parent-chain check the run loop itself uses. If not, it kicks the loop again to drain the queue. Guarded so plain aborts don't restart anything (the interrupted turn's aborted assistant message counts as handled) and synthetic-only messages (workspace move reminders) are skipped.

How did you verify your code works?

Added a regression test (cancel resumes a prompt queued mid-run): prompt A pinned behind a mock-LLM gate, prompt B submitted mid-run, then cancel — asserts B gets answered without being re-sent. Fails without the fix (times out waiting for the second LLM call), passes with it. Full packages/opencode suite and repo typecheck pass.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found a potentially related PR:

Related PR:

• fix(session): restart the loop for queued input stranded by an interrupt #40956 - fix(session): restart the loop for queued input stranded by an interrupt
  fix(session): restart the loop for queued input stranded by an interrupt #40956

This appears to be addressing the same or a very similar issue — restarting the loop when a queued input gets stranded after an interrupt. You should check if #40956 was a previous attempt at this fix, or if it handled a different scenario that your current PR #44810 builds upon or supersedes.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[rituparna-ui]

I see #40956 addresses the same issue (#40955) and was opened earlier — happy to close this one in favor of that if maintainers prefer.

Two differences in the check used here, flagging for whoever reviews either:

• Parent-chain vs ID ordering: this PR asks "did the newest user message get an assistant child" (assistant.parentID === lastUser.id), which is robust for imported sessions where message IDs aren't monotonic (same reason MessageV2.isAfter compares time.created before IDs). fix(session): restart the loop for queued input stranded by an interrupt #40956 compares lastUser.id > lastAssistant.id directly.
• Synthetic-only messages: this PR skips restart when the newest user message has only synthetic parts (e.g. workspace move/warp reminders sent with noReply), which must never produce a reply.

Otherwise the approaches are equivalent: both restart the loop after cancel settles, and both preserve bare-cancel semantics.

Also heads-up: this PR adds a test only for the resume path; #40956 additionally pins the "bare cancel does not restart the loop" behavior, which is worth having on whichever PR lands.

[rituparna-ui]

Update: the bare cancel does not restart the loop pin is now included here too (cancel without queued input does not restart the loop), alongside the resume regression test. Verified stable across repeated runs locally.