fix: support a host-owned idle steering fallback

[leehom0123]

If a Codex turn finishes just before _session/steering reaches it, the adapter starts another turn and returns startedNewTurn. The client never receives that new prompt's final response. If the original prompt is still waiting for plan approval, steering waits too, which can block clients that process steering and permission replies serially.

This adds the opt-in requested in #440:

{"_meta":{"steering":{"idleBehavior":"promptRequired"}}}

Live turns still receive the input through native steering. When no turn can accept it, the adapter returns promptRequired with reason: "noRunningTurn", leaving the input unconsumed and starting no new turn. The client can answer any pending approval, wait for the original prompt to finish, then send the input through a normal session/prompt. Calls without the option behave as before.

This builds on @fontanierh's patch in #441, cherry-picked with the original author and source reference preserved. I added regression tests for pending plan approval, malformed metadata tests, and usage documentation.

Fixes #440.

Testing

• 33 targeted tests passed. The pending-plan-approval steering tests timed out before the fix.
• Typecheck, build, and all six standalone binary targets passed.
• Tested idle, live-turn steering, and pending plan approval with real Codex. Steering returned in 1 ms while approval was pending; rejecting implementation completed the original prompt with its stop reason, usage, and quota.
• Full suite on Windows: 1,205 passed, 19 failed, 36 skipped. All 19 failures reproduced on unmodified main at 4583cb3, in history, attachment, and path assertions.

The real Codex tests used temporary local runners, adapted for the removed authRequired() call in the repository's test script. Cancellation dispatch has unit coverage; the real test used the reject-plan path.

For clients: promptRequired is a steering result, not completion of the original prompt or its approval request. The existing _meta.steering.supported flag also does not distinguish support for this option, so clients need to check the adapter version.

[leehom0123]

Merged latest main (a636804) and resolved the one conflict in performSteeringRequest: the host-owned promptRequired branch is kept, and the legacy fallback now forwards its clientUserMessageId through the new startNewTurnFromSteering(params, clientUserMessageId) signature from the ACP v2 rework.

Verification on Windows: typecheck passes; the 29 targeted steering/plan-approval tests pass. The full suite fails 70 tests in 10 files, and a run of the same 10 files on the unmodified main baseline fails the identical 70 — pre-existing Windows failures, none introduced by this merge.

@EugeneTheDev could you take a look at the conflict resolution, since it touches the steering path your v2 work changed? @fontanierh heads-up that #441's patch in this PR has been rebased over the v2 rework.