Nice. The "suppress notification if you're already focused on that pane" is a good detail, that's the kind of thing that separates useful from annoying.
I've been working on a similar problem (knowing when a terminal session needs attention) and settled on a 2-second interval comparing the last activity timestamp. If a PTY has been idle for >2s after previously being active, it probably wants input. Not perfect but surprisingly effective for Claude Code since it has distinct "working" and "waiting for input" phases.
Does the hooks approach catch all the cases? I'm thinking about things like Claude getting stuck in a confirmation prompt where it technically hasn't "stopped" but isn't making progress either.
The "sessions crash at 3am from context compaction" problem is real. I've been building terminal tooling and hit the same wall.
One thing I learned the hard way about tmux-based approaches: tmux sends screen redraws rather than raw output, which breaks scrollback in web-based terminal renderers (xterm.js specifically). If you're streaming tmux pane output to the web dashboard, you might run into this — the terminal looks fine but you can't scroll up through history. tmux control mode (-CC) fixes it by providing raw pane output, but it's a different protocol to parse.
The single-file approach is interesting. How are you handling the web dashboard —inline HTML served from the Python process? Curious how the live status detection works at the tmux level. Are you parsing pane content or watching for output activity on a timer?