fix(desktop): stop hidden previews draining battery

[Bil0000]

What changed

• Stop inactive Electron browser previews from painting while they remain mounted.
• Wake a hidden preview while background automation uses it. The lease is reference-counted so overlapping requests cannot suspend each other.
• Keep previews paintable during recording and native picture-in-picture.

Why

Hidden preview webviews were moved offscreen but left CSS-visible. Animated pages therefore kept the Chromium renderer and GPU processes busy after the preview panel closed.

In the current Nightly build, a hidden animated X tab used about 63% combined CPU across the T3 Code GPU, guest renderer, and main renderer processes. Hiding the whole app dropped the guest and GPU processes to 0%, which isolated the work to hidden foreground webview painting.

This complements #8018. That PR removes duplicate downstream work for static recording frames; this PR stops rendering when no visible or background consumer needs frames.

Fixes #3143.

Verification

• bun fmt
• bun lint
• bun typecheck
• 153 focused browser and preview tests
• bun run test: all affected and app tests passed; one unrelated, unchanged Windows packaging test fails locally on macOS (skips the primary native probe for cross-architecture Windows payloads)

Risk

Low. The change is limited to preview visibility. Regression tests cover inactive previews, active background work, and concurrent activity leases. Existing recording and picture-in-picture state keeps those consumers paintable.

Note

Suspend rendering of hidden desktop preview webviews to stop battery drain

• Offscreen/inactive webviews now set visibility: hidden and a data-preview-rendering="suspended" attribute unless renderingActive is true, stopping unnecessary paint work
• renderingActive is computed from three signals: a per-tab background activity lease (acquireBrowserSurfaceActivity in browserSurfaceStore.ts), picture-in-picture state, and active recording tab ids
• Automation requests in PreviewAutomationHosts acquire an activity lease for the target tab for the duration of the operation, and gate overlay/readiness checks on the webview actually rendering via isPreviewWebviewRendering
• Recording startup now publishes activeBrowserRecordingTabIdsAtom earlier (before screencast starts), changing the observable event order so publish:tabId precedes start-screencast
• Behavioral Change: startBrowserRecording event ordering changed — publish:tabId now fires before start-screencast; tests in browserRecording.test.ts updated accordingly. Inactive webviews that previously rendered offscreen are now hidden, which could affect anything that relied on offscreen paint without holding a lease.

^{Macroscope summarized cd53061.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6e6dc94b-00c1-444e-be5f-1075380b53af

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The change conditionally suspends rendering for all inactive desktop previews and adds coordination for automation, recording, and picture-in-picture consumers. Although the intent is clear and targeted tests are included, this is a cross-cutting runtime behavior change that merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

UI consistency review: two ownership findings on the new offscreen-rendering gate. The behavior change itself (suspending paint for idle offscreen guests) looks sound; the concerns are about where the "is this guest painting?" fact lives and about the Electron constraint documentation that was dropped with the old visibility: "visible" line.

^{Posted via Macroscope — UI Consistency}