fix: prevent macOS desktop unlock freeze after display sleep

[yuruiz]

Summary

Fixes #741.

On macOS, locking the screen until the display sleeps can leave the Paseo
desktop window frozen after unlock — clicks and keypresses do not land —
even though the renderer and every process stay alive. It self-recovers
after a few minutes. Strongest repro: the Mac mini / external-display wake path.

Root cause: macOS display sleep can leave Chromium's GPU-process display
link — the vsync source that drives frame production — stuck on a stale
display. The compositor then stops producing frames, so the window looks
frozen while actually being alive. Restarting the GPU process makes Chromium
rebuild the display link, and frames resume.

Changes

setupDarwinCompositorWatchdog (packages/desktop/src/window/window-manager.ts)
replaces the previous setupDarwinPaintRefresh:

• Polls the renderer for frame production every 2 s (requestAnimationFrame,
  bounded by a setTimeout so the probe resolves even when frame production
  has stopped).
• After 3 consecutive stalled probes (~6 s) — only while the window is visible,
  not minimized, and the screen is unlocked — restarts the GPU process with
  SIGKILL; Chromium relaunches it automatically.
• Bounded by a 60 s cooldown and a 3-attempt cap.

main.ts wires it in; window-manager.test.ts covers the
shouldRecoverFromFrameStall decision logic; docs/development.md documents
the gotcha. The previous setupDarwinPaintRefresh only nudged the window size /
invalidated the surface, which does not address the dead display link.

Note on the earlier revision

An earlier version of this PR attributed the freeze to a renderer-side
history-sync cascade and changed five app-layer files. Diagnostic builds showed
the freeze is frame-production death in the GPU process, not renderer
main-thread starvation — so the app-layer changes were dropped and this PR now
carries only the GPU-watchdog fix.

Verification

• Built the desktop app from this commit and ran it until a real freeze
  occurred. The watchdog detected the frame-production stall, restarted the GPU
  process once (no second attempt needed), and the window recovered — versus
  the ~3-minute unmitigated freeze.
• npx vitest run packages/desktop/src/window/window-manager.test.ts — 18 tests pass.
• npm run typecheck (all workspaces), npm run lint, npm run format:check — pass.

Risk / compatibility

• Desktop-only, gated to macOS (process.platform === "darwin"). No WebSocket
  or schema change.
• The watchdog acts only on a sustained stall while the window is visible and
  unlocked; cooldown + attempt cap bound it.
• The probe timer and all powerMonitor listeners are removed when the window closes.

Test plan

• Mac mini + external display: lock until the display sleeps, unlock,
  interact — the window recovers within seconds instead of staying frozen.
• MacBook Pro: normal lock/unlock — no regression.
• Normal use across display-sleep cycles — confirm no spurious GPU restarts
  when there is no real freeze.

[boudra]

hey @yuruiz apologies for the force push on main, i was going to rebase this but i see that you already merged. will look into your PRs in a moment.