fix(run): prevent early exit when no todos exist yet

[code-yeongyu]

Problem

oh-my-opencode run exits within ~1.5 seconds of starting because pollForCompletion checks completion too early.

Root Cause

When the agent outputs its first text (e.g. "ULTRAWORK MODE ENABLED!") but hasn't called todowrite yet:

1. hasReceivedMeaningfulWork = true (text was output)
2. Session briefly goes idle (agent pausing between reasoning/tool calls)
3. checkCompletionConditions: 0 todos = "all complete", 0 children = "all idle"
4. 3 consecutive checks at 500ms = exit 0 in ~1.5s

Note: Todo 0 = "all complete" is correct behavior — some agents don't use todos. The issue is timing, not completion semantics.

Fix

Add a minimum stabilization period (10 seconds, configurable) after the first meaningful work before checking completion conditions. This gives agents time to create todos and spawn child sessions without changing what "complete" means.

pollForCompletion loop:
  ... existing gates (idle, tool, work) ...
  NEW: if elapsed < minStabilizationMs since first work → skip completion check
  ... checkCompletionConditions ...

Changes

• src/cli/run/poll-for-completion.ts: Add MIN_STABILIZATION_MS = 10_000 and firstWorkTimestamp tracking
• src/cli/run/poll-for-completion.test.ts: Add stabilization period test, update existing tests with minStabilizationMs: 0 where needed

Testing

• 74 tests pass across 10 files in src/cli/run/
• New test: "does not check completion during stabilization period after first meaningful work"
• Existing tests use minStabilizationMs: 0 to opt out of the delay

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Requires human review: Test changes modify expected behavior (returns false instead of true for empty todos) and add new test data requirements. Cannot be 100% sure no regressions without verifying test logic matches meant:}

[code-yeongyu]

Superseded by #1783 which fixes the actual root cause: missing directory parameter in client.event.subscribe(). The stabilization period from this PR is included in #1783 as defense-in-depth.