Background

Guest sync fs/module RPCs are serviced by pump_process_events, which the stdio
select loop (crates/sidecar/src/stdio.rs) only runs on the EVENT_PUMP_INTERVAL
timer. PR #77 reduced that interval from 5 ms to 250 µs, which cut per-call
latency dramatically (stat 7.5s→1.3s, read 7.6s→1.2s over 1500 ops). But it is
still a polling timer: a blocked guest call waits up to one interval before the
host dequeues it, and the loop wakes on every tick even when nothing is pending.

Proposal

Make the pump event-driven: wake the stdio select loop the instant the
execution layer enqueues a process event (e.g. a JavascriptSyncRpcRequest),
instead of relying on the timer. Concretely, plumb a notify signal from the
execution event channel up into the run_async select loop (an extra select!
arm that awaits "a process event is ready"), and keep a coarse timer only as a
fallback. This removes the residual ~250 µs/call timer latency and the idle-tick
cost entirely.

Notes / constraints

• An adaptive fine/coarse interval was tried in PR perf(sidecar): cut guest fs RPC latency (fs-heavy workloads 5.7–41× faster) #77 and was unstable
  (oscillation/livelock under load) because it recreated tokio::time::interval
  mid-select. A true notify channel avoids that.
• pump_process_events already returns whether it did work; the receiver
  (process_event_receiver) is currently drained via try_recv inside the pump,
  so an event-driven design must coordinate a single consumer.

Expected impact

Removes the remaining timer latency on every guest sync fs/module RPC; biggest
remaining win for fs-heavy guests after PR #77.