Turn off continuous rendering for panes that are not visible in the app.

[aryeh]

What

It determines which panes are occluded (not visible on screen) and turns rendering off for them.

Why

Continual rendering of offscreen panes overload the CPU. >40% CPU with app out of focus.

Closes #110

How

Verified

UNVERIFIED! I do not have Xcode, and am unable to modify my dev environment at the moment, but this should be a relative easy review and/or fix with the issue directly outlined.

• mise run format, mise run lint, and mise run test all pass
• Built and ran the change in the app (mise run run) and confirmed the behavior
• Added or updated tests for new model / persistence / palette / hotkey logic

Notes for reviewers

[onliner10]

Thanks @aryeh. I folded the app-focus and per-surface occlusion approach from this PR into #111 so we can land one combined fix for #110.

That combined branch now includes the occlusion/focus behavior from here plus the activity-indicator fixes and regression tests from #111.

A larger warmed-tab benchmark lines up with the benefit you reported:

build/workload	active visible	hidden
origin/main, 70 warmed tabs	~8.28%	~8.20%
combined #111, same workload	~1.41%	~0.84%

Would you be okay with treating #111 as the landing PR for #110 and closing this one after #111 merges? If you think anything from this PR did not make it over, I can fold that in.

[aryeh]

I'm not fully understand what you are requesting, the effects, and your reasoning.

You want to remove my PR take the code and put it into your PR? Why not apply both or reject mine if it needs to be refactored?

Doesn't this ruin the provenance of code modifications and who it tracks back to? My understanding is that PRs should be accepted/rejected so everything tracks properly, not cut'n'pasted from one request into another.

[thdxg]

Thanks @aryeh! This is the real fix for the heavy half of #110.

One behavioral caveat before merge: parking the renderer also stops the render/scrollbar callbacks that feed the tab status indicator. On main, hidden surfaces wastefully render — but that rendering was what kept a hidden pane's activity spinner alive. With this PR, an occluded pane running an in-place TUI (e.g. btop) loses its render heartbeats and can be falsely quiet-settled to a "done" checkmark. OSC-based signals (133 command-finished, 9;4 progress, titles) are termio-side and unaffected, and the indicator is off by default, so this isn't a blocker.

Plan: I'll merge this and handle the guard in a follow-up (suspend quiet-settle for occluded panes so "no events while parked" reads as unknown rather than idle). Longer term the clean fix is in the ghostty fork — emit the scrollback-growth action from the io thread instead of the draw path — which I'll track separately.

Note: this doesn't close #110 entirely — a visible idle window still renders continuously (~10% of a core in the benchmarks), which neither this PR nor #111 touches. I'll keep the issue open with a scoped follow-up for visible-idle renderer scheduling. Appreciate the contribution!