Summary

Add structured tool failure diagnostics for ordinary errored tool calls.

This PR introduces a small failure classifier, persists metadata.diagnostics.failure on tool-error state, appends a concise model-facing recovery hint during message replay, and preserves only safe failure fields in raw/sanitized exports.

Why

Fixes #439.

Today ordinary tool failures are mostly flattened to an error string. That makes it hard for the agent to decide whether to fix arguments, stop after a user abort, ask for permission, check local setup, or report a provider problem. This keeps the original error text but adds a stable local reason and generic recovery hint.

Related Issue

Fixes #439.

Human Review Status

Pending. A human should make the final merge decision after reviewing the final diff and verification evidence.

Review Focus

• Whether the initial failure classifier categories are conservative enough.
• Whether metadata.diagnostics.failure is merged without disturbing existing loop diagnostics.
• Whether export sanitization preserves only safe generic fields and continues redacting raw input/error/metadata.

Risk Notes

• Model behavior may change for errored tool results because output-error.errorText now includes a short recovery hint.
• Misclassification could nudge the model toward the wrong recovery path. The fallback remains unknown.
• No migration is needed because the new metadata field is optional.
• No UI copy, telemetry, provider retry policy, or Bash timeout behavior is changed.

How To Verify

Targeted tests: 135 passed, 0 failed
Command: bun --cwd packages/opencode test test/session/tool-failure.test.ts test/session/message-v2.test.ts test/session/diagnostics.test.ts test/session/export.test.ts test/session/prompt-effect.test.ts

Typecheck: passed
Command: bun --cwd packages/opencode typecheck

Diff check: no whitespace errors
Command: git diff --check

Screenshots or Recordings

Not applicable. No visible UI change.

Checklist

• Human review status is stated above as pending, approved, or not required
• I linked the related issue, or stated why there is no issue
• This PR has type, scope, and priority labels, or I requested maintainer labeling
• I described the review focus and any meaningful risks
• I listed the relevant verification steps and the key result for each
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope
• I manually checked visible UI or copy changes when needed, with screenshots or recordings
• I considered macOS and Windows impact for desktop, packaging, updater, signing, paths, shell, or permissions changes
• I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant
• I reviewed the final diff for unrelated changes and suspicious dependency changes
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English