app-server: deflake running thread resume tests

[bolinfest]

Why

CI has been intermittently failing in suite::v2::thread_resume::thread_resume_rejoins_running_thread_even_with_override_mismatch because these running-thread resume tests treated turn/started as proof that the thread was already active.

That signal is too early for this path. turn/started is emitted optimistically from turn_start. In single_client_mode, the listener skips current_turn_history tracking in codex_message_processor.rs, so running-thread resume still depends on ThreadWatchManager observing the core TurnStarted event in bespoke_event_handling.rs. If thread/resume lands in that window, the thread can still look Idle and the assertion flakes.

What

• Add a helper in codex-rs/app-server/tests/suite/v2/thread_resume.rs that waits for thread/status/changed to report Active for the target thread.
• Use that public v2 notification as the synchronization barrier in the four running-thread resume tests instead of relying on turn/started.

Follow-up

This PR keeps the fix at the test layer so we can remove the flake without changing server behavior. A broader runtime fix should still be considered separately, for example:

• make turn/start eagerly transition the thread to Active so turn/started and thread/status/changed are coherent
• or revisit the single_client_mode guard that skips current-turn tracking for running-thread resume

Testing

• cargo test -p codex-app-server thread_resume -- --nocapture
• for i in $(seq 1 10); do cargo test -p codex-app-server 'suite::v2::thread_resume::thread_resume_rejoins_running_thread_even_with_override_mismatch' -- --exact --nocapture; done