Add dark mode support for content frame

[shaunandrews]

Summary

• Add system-preference dark mode (prefers-color-scheme: dark) for the content frame area while keeping the sidebar chrome permanently dark
• Define 14 CSS custom properties (--color-frame-*) with dark mode overrides, mapped to Tailwind tokens (frame-*)
• Enable Electron nativeTheme.themeSource = 'system' so the renderer respects OS preference
• Add dark mode CSS override block using :is() for WP component classes (inputs, buttons, tabs, modals, popovers, menus)
• Make the Button component dark-mode-aware by replacing hardcoded text-black/bg-white with frame-* tokens
• Migrate ~40 component files from hardcoded colors (text-gray-*, bg-white, border-gray-*, hex values) to semantic frame-* tokens

Test plan

• Toggle system appearance to dark mode and verify the content frame background changes to #2F2F2F
• Verify sidebar chrome remains unchanged in both modes
• Check all 6 content tabs (Overview, Sync, Previews, Import/Export, Settings, Assistant)
• Open the "Add a site" fullscreen modal and verify all text, inputs, and buttons are readable
• Open WP modals (Connect site, Edit site) and verify dark surfaces and text
• Check dropdown menus (preview site actions, assistant chat menu)
• Verify primary (blue) and destructive (red) button colors are preserved
• Test the assistant chat: messages, welcome prompts, input bar, Telex banner
• Switch back to light mode and verify no regressions

[wojtekn]

Hey @shaunandrews ! Thanks for working on that - it looks like an interesting addition. I think it would make sense to do the following before we pass it for review:

• Adding a setting allowing the user to choose between light mode, dark mode, and “follow system default” modes
• Adding e2e tests for new changes
• Fixing all failing builds

You could also consider adding it to the What's New dialog.

[shaunandrews]

I've updated the settings screen:

• I've added a new appearance setting for system, light, and dark modes. This setting is changes immediately, without having to click the save button.
• The new appearance setting has a tendency to cause the settings modal to scroll vertically, hiding the save button. To avoid this, I've removed some of the size restrictions around the modal height, and put the editor and terminal settings on the same row.
• I visually aligned the CLI switch with the first row of text.

[shaunandrews]

I also added to the What's new modal:

[wpmobilebot]

📊 Performance Test Results

Comparing 3a5fcc5 vs trunk

site-editor

Metric	trunk	3a5fcc5	Diff	Change
load	1480.00 ms	1459.00 ms	-21.00 ms	⚪ 0.0%

site-startup

Metric	trunk	3a5fcc5	Diff	Change
siteCreation	7138.00 ms	8077.00 ms	+939.00 ms	🔴 13.2%
siteStartup	4948.00 ms	4960.00 ms	+12.00 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[wojtekn]

@shaunandrews, thanks for adding settings UI. Some notes regarding UX:

• Currently, settings are not saved until the user presses Save, and it's different for dark mode. I think the new way is okay too, but it would be better to stick to one of those ways and use the same approach for all options.
• The buttons look a bit too expressive - do they add any value? What if we just used buttons with small icons inside?

[shaunandrews]

I made the appearance setting save immediately because it helps the user understand what the setting does as they can see the UI of the main window change immediately. I'm not opposed to changing the rest of the settings to work similarly, but this PR is already huge; would be a good follow up.

As for the buttons, I did try other options but felt the illustrations looked much better and helped convey the settings effects better than an icon. It's also a fairly standard pattern.