feat(web): system theme option — follow the OS prefers-color-scheme (stretch of #67)

[dchaudhari7177]

The stretch item from #67 ("a fourth system option that follows prefers-color-scheme"), as the separate PR the issue invited.

Builds on #89 — the light-theme PR. This branch contains #89's commit; the net new diff is the last commit (feat(web): system theme option). Happy to rebase once #89 lands.

pwa/theme.ts — the stored preference and the rendered palette are now distinct types: ThemeName (dark | oled | light, what tokens.css/xterm can render) vs ThemePreference (ThemeName | "system"). resolveTheme() maps "system" to light/dark via (prefers-color-scheme: light), using the same defensive matchMedia guard as AppLayout.useIsDesktop (jsdom/SSR → dark). watchSystemTheme() re-applies and re-announces rc-theme-change when the OS scheme flips — but only while the preference is "system", so a concrete choice never gets overridden.

main.tsx — starts the watcher immediately after the boot applyTheme, so a daylight/night OS switch restyles the app (and an open terminal, which re-reads its palette on rc-theme-change) live, no reload.

SettingsPanel.tsx — a fourth System option in the Theme select; still applies instantly.

Tests — extends theme.test.ts (8 passing): "system" round-trips and resolves per a stubbed prefers-color-scheme; without matchMedia it falls back to dark instead of crashing; the OS-flip watcher announces only while the preference is system (vi.stubGlobal matchMedia stub with a change-listener registry, the repo's existing idiom).

Verification — pnpm typecheck clean; theme tests 8/8. End-to-end in a real browser: with the stored preference "system", booting under an OS light scheme paints paper (data-theme="light", --bg #f6f6f7) and under an OS dark scheme paints near-black with the theme-color meta mirrored (#0a0a0b, attribute removed).

[dchaudhari7177]

Same situation as #89, which this was stacked on — main has replaced the theme system with the generated Ghostty catalog (ThemeName = string, surfaces derived per theme via isLightTheme / mix). This PR adds a fourth value to a three-value union that no longer exists, so there is nothing here to rebase.

Closing-worthy as written, but the gap it addresses is still open. I checked main before writing this: there is no prefers-color-scheme handling anywhere in packages/web/src — the only matchMedia calls are the min-width: 1024px and pointer: coarse ones in App.tsx / AppLayout.tsx. So "follow the OS" is still unimplemented, and the new architecture arguably makes it more worth having, since a user who picks a light Ghostty theme now has no way to have it revert after dark.

Against the new design it would be a different and smaller change than what is in this branch: a stored preference of "follow the system", plus a light/dark pair of catalog theme names, with isLightTheme() already available to validate the pair rather than hardcoding which is which.

Happy to close this and open that as a fresh PR if you want it — or to close it and leave the idea alone if system-follow is not a direction you want. Your call; I would rather ask than assume, given #89 is being closed for the same reason.