Windows: expose shared WinUI app icon helper for all top-level windows (including settings) #333

Problem

Rivet-generated Windows hosts embed the product icon in RT_GROUP_ICON resource ID 1 and Rivet's scaffold platform/windows/host/MainWindow.xaml.cpp explicitly installs that icon via AppWindow.SetIcon(IconId). This only covers the scaffold main window. First-party downstream windows (for example, Fulcrum's windows/SettingsWindow.xaml.cpp) must repeat fragile WinUI/Win32 glue. Fulcrum currently calls appWindow.SetIcon(exe_path), mistakenly passing an executable path to the string overload, which expects a .ico file path. The WinUI settings title bar therefore appears without the product icon, even when the EXE has a valid embedded icon. This is not intentional Windows platform style.

Earlier issues #166 and #282 fixed packaging/resource identity; this issue tracks the remaining secondary-window API and regression-contract gap rather than reopening those completed fixes.

Proposed narrow API

• Add a small opt-in rivet::system::ApplyAppIcon(Window const&) (or equivalent) in the WinUI-only system header, backed by the generated numeric ID 1 resource, using LoadIconW(GetModuleHandleW(nullptr), MAKEINTRESOURCEW(1)) and AppWindow().SetIcon(Microsoft::UI::IconId{...}); avoid the SetIcon(String) overload for exe paths.
• Document correct lifetime/ownership of HICON passed to AppWindow and what happens when no icon resource is present, so fallback is deterministic. Keep usage valid both before/after Activate() and in secondary settings/other top-level windows.
• Make the generated scaffold use the same helper. Do not override platform-native titlebar decisions of macOS or Linux; do not force an icon on borderless launcher overlays.
• Add a native Windows regression test using two titled WinUI windows and assert both obtain the expected resource icon, including the packaged installed host; check that an absent icon gracefully falls back without crashing.

Scope / ownership

• Rivet owns reusable Windows window-identity primitives, and the generated packaged icon.
• Products such as Fulcrum own their navigation, WinUI settings controls, brand art, and whether a window uses a title bar.
• Fulcrum's urgent fix should use the embedded icon directly without waiting for a new Rivet pin; this enhancement prevents future repeats across downstream applications.

Related: turinglambdaai/fulcrum#104 (planned v0.14.1 patch, including WinUI settings parity and icon fix).