beta: cancelled task remains running and blocks resume/amend

Summary

In the OpenCode v2 beta, cancelling a fixer/background task from one session can leave the task registered as running. A different session then refuses to resume or amend it, even though cancellation was attempted and reported as returned. This is reproducible and blocks cleanup/recovery of the task.

Environment

• opencode version: 0.0.0-beta-19296 (runtime snapshot; opencode/opencode2 was unavailable in the diagnostic shell)
• OS: Windows 11, build 26200.9168 (Microsoft Windows [Version 10.0.26200.9168])
• Terminal: xterm-256color environment; terminal application unavailable
• Shell: PowerShell 7 (agent reported C:\WINDOWS\system32\cmd.exe)
• Install/channel: beta
• Active plugins: C:/Users/User/.config/opencode/node_modules/superpowers, @vectorize-io/opencode-hindsight, and oh-my-opencode-slim

Reproduction

1. Open two OpenCode v2 beta sessions.
2. From one session, start a subagent/background task.
3. From the other session, attempt to cancel the task after it becomes stale or unresponsive.
4. Observe that cancellation returns an error similar to Session abort returned but task did not stay stopped … (unknown).
5. Attempt to resume or amend the same task.

Expected Behavior

After cancellation completes, the task should reach a definitive terminal state and the UI should allow it to be safely resumed only if it is actually resumable, or clearly report that it cannot be resumed.

Actual Behavior

The task remains reported as running. A later session shows messages similar to:

The stale fixer lane could not be stopped: task_cancel returned “Session abort returned but task did not stay stopped … (unknown).”
I will not edit overlapping files until the lane reaches a definitive terminal state.
The prior fixer lane remains unconfirmed and could not be cancelled, so overlapping review edits are paused until its state becomes definitive.

The UI also reports:

Task <task-id> is still running and cannot be resumed or amended with task().

Additional Context

• Frequency: happens consistently for this workflow.
• The task was launched/observed from one session and the cancellation/resume attempt was made from another session.
• The screenshot shows the persistent still running and cannot be resumed or amended state.
• This may be a shared background-service/task-state race: the abort request returns, but the server-side task/session record is not reconciled to the stopped state before another session checks it.
• Related, but not exact, reports: #27827 and #28995 (background task cancellation/status mismatch).