perf(desktop): show the first window the moment Electron is ready - #49869

Users saw nothing for ~900 ms after launch. Three things were serial:

1. index.ts did await import("./desktop") — Electron holds ready until the entry module finishes, so the whole main bundle evaluated before Chromium was even ready
2. windows were created only after every layer had built
3. they were show: false until the renderer had painted and reported its theme colour over IPC (and the renderer waits for the first-launch check before doing that)

flowchart LR
  subgraph before
    a[Node ready 60] --> b[main bundle evaluates] --> c[ready ~390] --> d[layers] --> e[window created ~520, hidden] --> f[renderer paints + theme IPC] --> g[shown ~890]
  end
  subgraph after
    h[Node ready 60] --> i[tiny entry: configure, lock, scheme] --> j[ready ~220] --> k[window shown ~250] --> l[import desktop] --> m[layers adopt window, loadURL] --> n[renderer paints into the visible window ~810]
  end

What moves where

• index.ts is now small: configureApplication() (paths, app id, command-line switches, test root — everything that must precede ready, now synchronous in lifecycle/configure.ts), the single-instance lock, registerRendererScheme() (windows/scheme.ts; the privilege call must precede ready), then on ready: createEarlyWindow() and only then import("./desktop")
• windows/early.ts creates the first restored window: id from the persisted window list, bounds from its state file, background from the persisted theme colour, the same frame/preload options as windowAppearance (shared via windows/defaults.ts), and shows it. Closing it before adoption quits the app.
• restoreWindows() adopts it (takeEarlyWindow()): security wiring, registry, loadURL as before; reveal() is already satisfied. New windows opened later keep today's behaviour.
• Import ordering was measured both ways: starting the import before ready is worse on every milestone (window 276 → 434 ms) because the module graph evaluates on the thread Chromium needs to finish initialising.
• electron-context-menu moves out of configuration and installs after restoreWindows() (it attaches to existing and future windows), which also keeps its dependency tree off the startup path — supersedes perf(desktop): install the context menu after the first window exists #49794
• The bench reads the early window's shownAt from the adoption log line, since the logger doesn't exist yet when the window is shown.

Measured with bun run bench:startup --compare (interleaved launches, warm service, median of 5, current v2 as baseline):

The trade: the frame is on screen 640 ms earlier and the splash paints 250 ms earlier; the main bundle now starts after the window exists, so the shell lands ~100 ms later. Main-thread CPU in the first half second is saturated either way — this changes what the user sees first, not how much work there is. Reducing the bundle and layers (the other PRs in this series) shortens the remaining gap.

Also tried, parked on branch early-renderer: loading the renderer into the early window before the layers. Renderer process 600 → 259 ms, but the main thread then serves its chunks and the RenderProcessHost while the bundle evaluates: first paint 814 → 778, shell 1,135 → 1,087, idle 1,676 → 1,578, while the first log line slips 457 → 605 and service ready 578 → 856 (bad for cold starts). Not a clear win; separate decision.

The ~250 ms is close to the platform floor: Node bootstrap completes at ~60 ms, Electron's own JS init and Chromium's main-loop setup take it to ready at ~220, BrowserWindow is ~30.