fix: stabilize idle timeout sender tests

[BunsDev]

Summary

• Stabilize IdleTimeoutSender tests by polling for delayed oneshot delivery instead of relying on a fixed post-timeout sleep.
• Keep the existing immediate None assertion so the tests still verify that delayed sends do not complete before the timeout.
• Leave production sender behavior unchanged.

Root Cause

The macOS 26 scheduled CI runner failed idle_timeout_sender_later_send_after_supersedes_earlier because the test slept for 100ms after scheduling a 50ms timer and assumed the spawned timer thread had also been scheduled and delivered by then. Under CI load, the receiver was still empty, producing left: None, right: Some(2).

Verification

• cargo nextest run -p warp-app idle_timeout_sender --features gui --profile default
• cargo fmt --check
• ./script/check_ai_attribution
• ./script/check_rebrand
• cargo check -p warp-app --bin cast-codes --features gui

[Copilot]

Pull request overview

Stabilizes the IdleTimeoutSender unit tests by replacing a fixed post-timeout sleep with a polling helper that waits up to a bounded duration for oneshot delivery, reducing CI scheduling flakiness without changing production sender behavior.

Changes:

• Add a recv_within helper that repeatedly try_recvs until a timeout.
• Replace sleep + try_recv assertions with recv_within(..., 1s) in the delayed-delivery and “later send supersedes earlier” tests.
• Keep the existing immediate None assertion to ensure delayed sends don’t complete before the configured timeout.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[BunsDev]

Pushed 3925c9c to fix the CI blocker: the new tests imported std::time::Instant, which this repo's clippy::disallowed_types lint forbids (it's not implemented for wasm targets). Swapped to instant::Instant — the same type the rest of the crate already uses — keeping Duration from std.

Heads up on the prior Run Windows tests failure: the only failing test was terminal::local_tty::windows::child::tests::test_event_is_emitted_when_child_exits, a Windows-specific terminal child-exit test unrelated to this PR (which only touches app/src/ai/agent_sdk/driver_tests.rs). It looks like an environmental/flaky failure and should clear on re-run.