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

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.

Start in tui/ui/event_loop.rs and trace the engine, dispatch, and translation channel producers, including whether the input path awaits send() on the 32-slot op channel. Compare the existing adaptive frame limiter with the proposed wake-driven design. Done means no try_recv polling remains on this path and measured idle CPU and input latency improve without regressing frame limiting.

Written by the indexing model from the issue text.