fix(cli): flush missed parts when run goes idle - #50453

Problem

Non-interactive opencode run --format json intermittently exits 0 with empty stdout even though the backend recorded output. Observed with run --attach (also reproducible without it): a short assistant reply such as OK is stored server-side (verified in the session database), but the CLI prints nothing — downstream consumers see an empty turn.

Root cause in loop() (packages/opencode/src/cli/cmd/run.ts):

1. Text is printed only on message.part.updated with part.time.end set.
2. The loop breaks the moment session.status turns idle.

If idle wins the race against the final part update (typical for instant, short answers — long streamed replies almost always win), the client exits before printing anything. The codebase already knows transports can drop status events (stream.transport.ts: "some transports can miss status events"); this is the inverse direction with no mitigation at all.

Fix

• Track mirrored part IDs in the live loop.
• On idle, re-fetch the session timeline via client.session.messages() and mirror finished text / reasoning (when --thinking) / completed-or-errored tool parts that were never streamed, reusing the exact same rendering path (outputPart()), so live and flushed output are identical.
• Best-effort: fetch failures keep the previous behavior.
• The live-loop branches are refactored to call the shared outputPart() with no behavior change.

Verification

• New unit tests: packages/opencode/test/cli/run/flush-missed-parts.test.ts (9 tests: missed finished parts, already-emitted skip, unfinished skip, thinking gate, tool statuses, user-message exclusion, synthetic-signal exclusion, empty timeline).
• Existing test/cli/run/run-process.test.ts subprocess suite: 13/13 pass (covers the refactor).
• tsgo --noEmit clean; oxlint reports no new warnings on touched files.
• Manual: patched CLI run against a live server returns the expected step_start + text JSON lines repeatedly with no duplication.

Notes

• Completed tool calls were already executed server-side; the flush only renders them, never re-runs.
• session.messages() lookup is by session ID only (same as the existing session.get usage), so this works for attach and local runs alike.