Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.

Current behavior

Follow-up to #300 / #439. Idle herdr still burns CPU because several idle
paths wake on fixed timers even when nothing changed. Two have already been
narrowed — the PTY actor was made event-driven in 78b13ac (keeps a 1s
fallback tick), and 0efd8ea skips re-extracting screen text on an unchanged
grid — but the rest still poll, and CPU scales with pane count:

• Agent detection — wakes every 300/500ms per pane and reads /proc
  (foreground_process_group_id) every tick, even on an unchanged grid.
  0efd8ea skips only the screen-text scan, not the wake or the /proc read.
• Client writer thread — recv_timeout(5ms) busy-poll on two channels
  (~200 wakes/s) per attached client.
• Render — idle agent panes force a full re-render every ~800ms (stable
  visible-signal refresh), and output from a background/hidden pane wakes the
  render loop even though nothing on screen can change.

Expected behavior

Idle herdr should sit near 0%. Keystrokes and PTY output wake the work, timers don't, i.e. should go event driven.

Reproduction

1. herdr with ~30+ idle zsh panes; check top -p $(pgrep -f 'herdr server')
   detached, then attach a client and check again.
2. strace -f -c -p <server-pid> — steady timer-driven /proc reads and wakes
   with no pane producing output; rate scales with pane count.

Impact

Wasted battery on laptop

Environment

• Herdr version: 0.7.0
• Update channel (stable or preview): stable
• Operating system: Linux 6.18 (Manjaro)
• Terminal: Guake
• Shell, if relevant: zsh
• Relevant config, if any: default