[Fix] Tasks abort on OpenCode provider rate-limit errors

[roomote-roomote]

Opened on behalf of Matt Rubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

N/A — internal Roomote work from Slack request to auto-retry OpenCode provider rate limits.

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

What changed

When OpenCode surfaces a provider rate limit as a terminal session.error — including OpenRouter-style UnknownError payloads like {"code":429,...,"error_type":"rate_limit_exceeded"} — the worker harness no longer aborts the task immediately.

Instead it:

1. Posts a short “automatically retrying” notice
2. Backs off (Retry-After when present, otherwise exponential, capped)
3. Submits an invisible continue prompt so the model resumes
4. Preserves already-queued user follow-ups across the wait
5. Keeps that continue prompt ahead of steers queued during backoff
6. Clears the backoff timer and retry budget on cancel so a later resume is not blocked

After a few failed attempts it still falls through to the existing terminal abort path. Successful later turns reset the retry budget.

How it was tested

• Unit tests for rate-limit detection, backoff, and notice text
• Harness tests for successful auto-retry, retry exhaustion, session.idle during backoff, steer ordering during backoff, and cancel clearing the backoff timer
• Worker typecheck + pre-push lint/knip gates

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

[roomote-roomote]

No new code issues found. See task

• apps/worker/src/sandbox-server/lib/harnesses/opencode-server/harness.ts:2143-2156 Preserve the hidden rate-limit continuation ahead of steers queued during backoff. A normal web/Slack steer sets autoSteerWhenQueued, so prioritize() moves it in front of the already-prioritized retry prompt; when the timer expires the user prompt runs first and the stale hidden Continue runs after that turn, potentially duplicating work.
• apps/worker/src/sandbox-server/lib/harnesses/opencode-server/harness.ts:2212-2213 Clear the provider retry timer and reset its counter when cancelling. A cancel during backoff currently leaves the timer pending, so a subsequent resumable SendMessage is queued until that stale delay expires and future rate limits inherit the cancelled turn's consumed retry budget.

_{Reviewed e09406b}

[roomote-roomote]

Fixed both review findings in e09406b:

1. Steer reorder during backoff — when a web/Slack steer is prioritized during rate-limit backoff, the hidden continue prompt is re-frontloaded so the automatic retry still runs first.
2. Cancel during backoff — cancel now clears the provider retry timer and retry count, so a follow-up SendMessage is not held by the stale delay and new rate limits get a full retry budget.

Also covered with harness tests for both cases. Browser proof n/a (harness-only).