[FEATURE]: Sanitize interrupted running/pending tool parts on subagent resume #50214

Verification

• I have checked that this feature has not been suggested before. Related existing issues are referenced below.

Problem

When a background subagent (spawned via the task tool) is interrupted mid-flight — by a service crash, OOM kill, network drop, or provider hang — the tool parts remain in running or pending state in the database. On resume via task_id, the orchestrator detects these orphaned parts but has no way to distinguish a genuine crash from a user-initiated cancel.

This causes two concrete issues:

1. Stale running parts block resume: The resume path previously used .find() which only sanitized the first running tool part, leaving others orphaned.
2. No crash-vs-cancel distinction: Both user cancels and crashes produce the same state=error with no metadata, making it impossible for the parent to decide whether to retry.

Current behavior (from source)

• packages/opencode/src/tool/task.ts resume path: when task_id is provided, the code fetches the last message and sanitizes tool parts. The original .find() only caught the first running part.
• packages/schema/src/v1/session.ts: ToolStateRunning has status: "running", ToolStatePending has status: "pending" — both are incomplete states that should be resolved on resume.
• MessageV2.toModelMessages treats both running and pending tool parts as incomplete, so orphaned parts silently break model context.

Proposed solution

In the resume path of task.ts, before re-prompting:

1. Iterate ALL tool parts in the last message (not just the first) using for...of with continue.
2. Sanitize both running and pending parts to state=error with:
   • metadata.interrupted = true — distinguishes crash from user cancel
   • time.end = Date.now() — ensures end >= start invariant
   • Preserve metadata from running parts (e.g. markers, debug info)
3. Exclude interrupted errors from terminal detection: failedInLast should filter out metadata.interrupted parts so sanitized orphans don't cause false-positive failures.

Acceptance criteria

• After a service crash, resuming a background subagent via task_id sanitizes all orphaned running and pending tool parts to error with metadata.interrupted=true.
• The parent session receives state=error with a recovery_hint containing the task_id, allowing retry.
• User-initiated cancels do NOT set metadata.interrupted (they use the existing cancel path).
• All 28 unit tests in test/tool/task.test.ts pass, including new tests for pending sanitization and historical error handling.

Related issues

• [FEATURE]: Orchestrator agent for parallel subagent fan-out/fan-in (parallel dispatch without polling) #47639 — Orchestrator agent for parallel subagent fan-out/fan-in: the parent feature this fix supports. Background subagents need crash resilience to be useful in production.
• Hot reload MCP server configuration #37421 — Hot reload MCP server configuration: unrelated but referenced in [FEATURE]: apply plugin / MCP / config changes without restarting the running session #39987 for config resilience.

Implementation notes

• Single file change: packages/opencode/src/tool/task.ts (~22 lines changed)
• Test additions: packages/opencode/test/tool/task.test.ts (3 new tests, 28 total)
• Validated E2E in isolated lab: kill service mid-flight → restart → resume → tool parts sanitized correctly
• Quality gate: independent reviewer + tester passed with zero findings

Happy to open a PR if maintainers agree on the direction.