Summary

• Preserve existing harness diagnostics when tools update running tool metadata.
• Add regression coverage for repeated successful Bash calls after Bash output metadata updates.

Why

Bash updates state.metadata while it streams output. That replaced the loop diagnostics attached on tool-call, so successful repeated Bash commands were invisible to the loop gate. In the #489 export, the same git diff command ran 39 times without the expected reminder, block, or stop.

This fixes the shared Tool.Context.metadata boundary instead of special-casing Bash, so tool-owned display metadata and harness-owned diagnostics can coexist.

Related Issue

Closes #489

Human Review Status

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

Review Focus

• The metadata merge order in SessionPrompt: new tool metadata such as Bash output should still update, while diagnostics.loop and diagnostics.failure remain intact.
• The new regression test proves repeated successful Bash exact-input calls hit the existing 3/4/5 loop gate.
• No Bash execution, permission, timeout, truncation, or loop threshold behavior changed.

Risk Notes

Low implementation risk, but the touched boundary is shared by tools that call ctx.metadata(). The focused tests cover Bash streaming metadata plus existing diagnostics, loop-gate, and Bash behavior.

How To Verify

Red test before fix: bun test test/session/prompt-effect.test.ts --test-name-pattern "loop gate stops repeated successful bash calls after metadata updates" failed with 5 completed Bash parts instead of 3.
Focused regression after fix: same command passed, 1 test, 27 expect calls.
Focused tests: bun test test/session/prompt-effect.test.ts test/session/diagnostics.test.ts test/session/loop-gate.test.ts test/tool/bash.test.ts: 129 passed, 0 failed.
Typecheck: bun run typecheck in packages/opencode passed.
Diff check: git diff --check had no output.

Screenshots or Recordings

Not applicable. This is session harness behavior with no visible UI layout 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, primary area, 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 platform, 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