UI event loop: wake-driven multiplexing instead of try_recv polling

[Hmbown]

From the 0.9.14 refactor backlog (async discipline pass).

tui/ui/event_loop.rs multiplexes by try_recv() on engine/dispatch/translation channels inside a poll loop with adaptive timeouts. It is well tuned, but still spin-and-sleep: input latency has a poll-interval floor and idle CPU never fully reaches zero.

Rust-native fix: wake-driven multiplexing — crossterm EventStream + tokio::select! over {input, engine rx, dispatch rx, timers}, or keep the dedicated UI thread and replace channel polling with a waker the producer pokes (futures::task::AtomicWaker). Keep the adaptive frame limiter; it is orthogonal. Verify first that nothing on the input path awaits send() into the 32-slot op channel (see the TurnSpec issue).

Size: M. Evidence: measured idle CPU and input latency before/after.

[Hmbown]

Triage (v0.9.14 run, structural — not in #6161): poll-and-drain sites verified at event_loop.rs:1555, 1602, 1836, 7291. The change is a loop rewrite (crossterm EventStream + select!) and the issue's own acceptance needs measured idle-CPU/input-latency before/after — it cannot ride a cleanup PR.

[Hmbown]

Deferring past the 0.9.14 cut (Size M + needs idle-CPU/latency evidence): the try_recv poll loop is well-tuned and nothing in the release requires the wake-driven rewrite. Finding 2/3 of #6191 (drain lumps, knob table) point here when it gets scheduled. Moving to Backlog.