fix: await event loop in non-interactive opencode run

[hardes11]

Issue for this PR

Closes #26855 (originally reported as #29131, which was a duplicate)

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes opencode run --format json exiting before the event stream completes. In non-interactive mode, loop() was called fire-and-forget (.catch(), not awaited). When prompt() returns the HTTP ack, execute() returns, the Effect framework disposes the in-process server, and the SSE stream dies before the model finishes generating.

Only step_start was emitted. text and step_finish were lost.

The change stores the loop promise and awaits it after the prompt/command call, keeping the process alive until the session reaches idle.

How did you verify your code works?

• Build: bun run build --single --skip-embed-web-ui → smoke test passed
• Before fix: opencode run "what is 2+2?" --format json emits only step_start
• After fix: emits step_start, text (with "4"), step_finish
• Also verified with opencode run "search arxiv for..." --format json — tool_use events now appear
• Full typecheck passed (bun turbo typecheck, 15/15 packages)

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[lmeyerov]

This matches a bug we keep hitting. We run opencode headless (opencode run --format json) to benchmark Bedrock models, and the assistant's final text gets dropped: execute() returns as soon as prompt() resolves, before the loop drains the final text/step-finish/idle events, so the in-process server tears down mid-flush. This PR's await fixes it. Minimal repro: ask for 58 + 71 and you get empty stdout on dev, 129 with this PR. Confirmed across several Bedrock models.

It's actually a re-regression: #26955 added this await, then #27371 dropped it while reworking exit handling (moved the exit code onto result.error and detached the loop again).

On testing: the run-process.test.ts happy-path assertion passes even on the un-awaited code, because the in-process TestLLMServer delivers events fast enough that the detached loop wins the race. So a non-empty-stdout assertion isn't a sufficient guard; catching this needs latency injected before the final events so a detached loop deterministically loses.

One small suggestion: early-returning on result.error before the await avoids a hang if a request never starts a run (e.g. an unknown command, which never emits idle).