Skin is a launch-time choice; stop applying it to a live window

Switching Modern -> Win7 at runtime broke the UI. SettingsService.applySkin
toggled the `.win7` class the moment the setting changed — harmless when there
was one component tree, and a broken window as soon as there were two. The tree
is bootstrapped once from the preload-baked __APP_SKIN, so the live flip painted
7.css onto shadlike markup that has no .window.glass, no .title-bar, no
menu[role=tablist] and no <table> ListView. The CSS landed on a tree that cannot
receive it.

A reload would not have helped, and neither would anything short of a restart:

- The preload is a persistent WebKitUserScript injected at DOCUMENT_START, so
  its string is frozen at webview construction — loadURL() re-runs it with the
  OLD __APP_SKIN. updatePreloadScriptToWebView exists in the FFI but is
  reachable only from electrobun's internal <electrobun-webview> handler.
- titleBarStyle/transparent have no setters; a live window cannot be re-framed.
  win7 -> modern is the dangerous direction — the modern tree draws no title
  bar, so it would land in a frameless transparent window with no way to move,
  minimize or close it.
- Recreating the main window is also out: exitOnLastWindowClosed is true, the
  main rpc is captured by six push closures, the tray captures `win`, and
  listeners cannot be removed.

So: applySkin is deleted outright, from setSkin AND from applyAll — the latter
matters independently, since applyAll runs on the settingsChanged push and was
therefore breaking every open editor and manager window too. Clicking a skin now
only persists it.

Also fixed a second leak found while tracing this: manager-window and
editor-windows build from `currentSettings()`, the LIVE snapshot, so a window
opened after a pending change would boot the new tree and frame while main still
ran the old one. `initSessionSkin` now freezes the skin at startup before any
window exists, and buildPreload/chromeOptions read that pinned value —
chromeOptions loses its parameter so no call site can get it wrong.

The options row shows the saved value as pending (skinPending() compares
settings.skin() against APP_SKIN) with the hint retexted in all 7 locales; it
said "Reopen the window to change its frame", which described the deleted
design.

Verified: tsc + build:ui clean; both skins boot correctly from a persisted
setting (win7 frameless, modern with the native frame). The live flip is now
impossible by construction, which is the check that matters here — the UI bundle
contains no classList write for win7 at all, the only writer is buildPreload,
and sessionSkin has exactly one assignment site.

Not verified: the click itself and the pending hint appearing, which need an
interaction pass — no window automation is available here. Both are present in
the built bundle.

Co-Authored-By: Claude <noreply@anthropic.com>

src/bun/windows.ts

@@ -1,6 +1,27 @@
 import { BrowserWindow } from "electrobun/bun";
-import type { AppSettings } from "../shared/types";
+import { DEFAULT_SETTINGS, type AppSettings } from "../shared/types";
 
+/**
+ * The skin THIS PROCESS booted with, frozen at startup by `initSessionSkin`.
+ *
+ * Every window must be built from this, never from the live settings snapshot.
+ * The skin picks a whole component tree (bootstrapped from the preload-baked
+ * __APP_SKIN) and the native frame (constructor-only), so it cannot change
+ * without a restart — but the persisted setting CAN change mid-session. Reading
+ * the live value would boot a newly opened editor or manager into the pending
+ * skin while the main window still runs the old one: two windows, two trees,
+ * two frames.
+ *
+ * Pinning it in one place makes that impossible rather than making each call
+ * site remember. Everything else in the preload keeps using the live snapshot,
+ * because theme/tone/accent/text-size genuinely do apply live.
+ */
+let sessionSkin: AppSettings["skin"] = DEFAULT_SETTINGS.skin;
+
+/** Call once, at startup, before any window is constructed. */
+export function initSessionSkin(skin: AppSettings["skin"]): void {
+	sessionSkin = skin;
+}
 
 /**
  * The preload globals every window gets. Single composition point: the UI
@@ -18,16 +39,19 @@ export function buildPreload(
 	settings: AppSettings,
 	ctx?: unknown,
 ): string {
+	// sessionSkin, NOT settings.skin — a pending skin change must not leak into
+	// a window opened before the restart. See initSessionSkin.
 	let script =
 		`window.__APP_PLATFORM=${JSON.stringify(process.platform)};` +
 		`window.__APP_MODE=${JSON.stringify(mode)};` +
-		`window.__APP_SKIN=${JSON.stringify(settings.skin)};`;
+		`window.__APP_SKIN=${JSON.stringify(sessionSkin)};`;
 	if (ctx !== undefined) script += `window.__APP_CTX=${JSON.stringify(ctx)};`;
 
 	// A class, not a data-* attribute: 7.scoped.css is precompiled to require a
-	// literal `.win7` ancestor, so the name is not ours to choose. Mirrors
-	// SettingsService.applySkin, which owns it once the page is live.
-	if (settings.skin === "win7") {
+	// literal `.win7` ancestor, so the name is not ours to choose. This is the
+	// ONLY place it is ever written — the UI must never toggle it live, because
+	// each skin's CSS is written against its own tree's markup.
+	if (sessionSkin === "win7") {
 		script += `document.documentElement.classList.add("win7");`;
 	}
 
@@ -46,12 +70,13 @@ export function buildPreload(
  * Native chrome options for a window. The ONE place the frame decision is made —
  * both the main window (src/bun/index.ts) and openSecondaryWindow spread this.
  *
- * Both values are BrowserWindow CONSTRUCTOR options, which is exactly why a
- * skin change only reaches the frame on the next window open: there is no API
- * to re-decorate a live window. SettingsService.applySkin flips the CSS half
- * immediately, and the options row tells the user about the gap.
+ * Both values are BrowserWindow CONSTRUCTOR options — there is no API to
+ * re-decorate a live window — which is half of why the skin is a launch-time
+ * choice. Takes no argument on purpose: it reads the pinned sessionSkin, so no
+ * call site can accidentally frame a window from a pending setting.
  */
-export function chromeOptions(skin: AppSettings["skin"]) {
+export function chromeOptions() {
+	const skin = sessionSkin;
 	// win7 draws its own Aero title bar (drag region + our minimize/maximize/
 	// close), so the window is frameless on EVERY platform. `titleBarStyle:
 	// "hidden"` clears `Titled` from the Cocoa style mask, which is also what
@@ -141,7 +166,7 @@ export function openSecondaryWindow(opts: SecondaryWindowOptions): BrowserWindow
 		title: opts.title,
 		url: opts.url,
 		frame: opts.frame,
-		...chromeOptions(opts.settings.skin),
+		...chromeOptions(),
 		preload: buildPreload(opts.mode, opts.settings, opts.ctx),
 		rpc: opts.rpc,
 		hidden: true,