Improve settings window load performance

[danielchalmers]

Problem

Since the recent settings-page additions (#140, #142) and the dark retheme (#138), opening the settings window felt slow, flashed a white rectangle before the dark content appeared, and visibly jumped to the saved scroll position after rendering.

Profiling with instrumented harnesses (clock running, pixel-sampling the screen during open) attributed it to three independent causes:

1. ~85 ms of every open was TimeZoneInfo.GetSystemTimeZones() + system font enumeration running synchronously in the viewmodel constructor.
2. The white flash was always there — a window's surface is white until WPF presents its first frame, and DWM fades the window in before that. Pre-Windows 11 retheme: dark mode, accent color, and Fluent control templates #138 the page was light so it was invisible; dark mode exposed it.
3. The scroll restore ran a dispatcher pass after the first frame, so the page rendered at the top and then jumped to the saved position.

Ruled out along the way: no individual control is heavy (30 chip buttons ≈ 13 ms; all checkboxes/textboxes/combos/sliders combined ≈ 50 ms cold across the 845-element tree), card drop shadows ≈ 0 ms, and deferring all below-fold sections saves only ~50 ms because ~125 ms is fixed window-materialization + XAML parse cost.

Fix (one commit each)

• Background enumeration (6c6fcbf): fonts and time zones are fetched once on a background task started while the app is idle after startup. If settings opens first, the binding just waits for the remainder — never slower than before.
• Themed background erase (40cab14, restored in 5b89ee4): the settings window handles WM_ERASEBKGND and fills the client area with the palette's WindowBackgroundBrush color via GDI, which lands before WPF's first frame. The color is read at message time, so dark/light/high-contrast and live theme switches all behave, and it also covers regions exposed during resizes.
• First-frame scroll restore (f12109f): the saved scroll offset is applied within the initial layout pass, verified programmatically — the first rendered frame is already at the saved position.

Measured (screen pixel sampling at the window center during open, Debug)

	before	after
fade-in blends toward	#FFFFFF, holds solid white ~55 ms	#202020 (theme background)
white frames observed	yes	none
scroll position	jumps after first frame	correct in first frame
click → fully rendered	~335 ms	~250 ms (vs ~350 ms before the redesign)

The open now reads as: themed window fades in, content appears once in its final position, nothing shifts. No window lifecycle changes or DWM tricks.