Stage 5: wire the skin switch — both UIs now reachable

The reunion is complete: one build contains both UIs and picks between them at
bootstrap.

- src/shared/types.ts regains `skin: "modern" | "win7"` on AppSettings.
- SettingsService regains the skin signal, setSkin() and applySkin(), which
  toggles the `.win7` class on <html>.
- buildPreload emits __APP_SKIN and adds `.win7` conditionally again, instead
  of unconditionally as it had since fe028a9.
- chromeOptions() regains its parameter: win7 gets frameless + transparent,
  modern gets the macOS hiddenInset fusion or the plain native frame.
- core/platform.ts regains APP_SKIN / IS_WIN7_CHROME (added in stage 4).
- main.ts now selects on both axes — skin picks the tree, APP_MODE picks the
  root within it.
- Both tab-bars get a skin row, with the reopen caveat as its tooltip.

DEFAULT_SETTINGS.skin is "modern", matching the original design and `main`.
Worth flagging: this branch has booted win7 unconditionally since fe028a9, so
after this commit it starts in the modern UI unless the setting says otherwise.
One word in types.ts flips that if the win7 look should be the default.

i18n: en.ts is the source of truth and everything else falls back to it, so
only en was strictly required — but es/eu/fr/de/zh/ja got real translations
too, each matching the terminology that locale already uses for the Theme row.

Verified both skins on live single-instance captures. Modern boots and renders
fully styled, which also proves Tailwind scans skins/shadlike/** — a purge
would have produced an unstyled page rather than this one. Win7, selected by
setting skin in the persisted settings, is still pixel-identical to the
pre-refactor baseline across all five stages. The persisted settings file was
backed up and restored, so it still carries no skin key and resolves to the
default through the backend's merge.

Not verified: clicking the new skin row itself, which needs an interaction pass
— no window automation is available here. Its bindings compile and the built
bundle contains options.skin, setSkin and the translated labels.

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

ui/src/main.ts

@@ -1,10 +1,19 @@
 import { bootstrapApplication } from '@angular/platform-browser';
 import { appConfig } from '@core/app.config';
-import { APP_MODE } from '@core/platform';
+import { APP_MODE, APP_SKIN } from '@core/platform';
 import { SEVEN_ROOTS } from './app/skins/7like';
+import { SHAD_ROOTS } from './app/skins/shadlike';
 
-// One bundle, three window kinds: the preload global picks the root component.
-// A second axis (skin) joins APP_MODE here once the shadlike tree lands.
-const tree = SEVEN_ROOTS;
+// One bundle, two skins x three window kinds. Both globals are baked into the
+// preload (src/bun/windows.ts buildPreload) because both are needed before the
+// first paint: settings arrive over an async RPC, far too late to choose a
+// component tree without flashing the wrong UI.
+//
+// Every skin's barrel exports the same { main, manager, editor } shape, so this
+// file never learns anything about either tree's internals. Both are imported
+// statically and ship in one bundle — the inactive skin costs bundle size but
+// no runtime work, which is the right trade for a local desktop app and keeps
+// bootstrap synchronous.
+const tree = APP_SKIN === 'win7' ? SEVEN_ROOTS : SHAD_ROOTS;
 const root = APP_MODE === 'editor' ? tree.editor : APP_MODE === 'manager' ? tree.manager : tree.main;
 bootstrapApplication(root, appConfig).catch((err) => console.error(err));