feat(compile): embed comctl32 v6 manifest so Windows UI apps get themed controls

[proggeramlug]

What

The biggest fix for the "controls look 40 years old" complaint in discussion #3486. Compiled Windows UI apps bound comctl32 v5 because Perry embedded no application manifest into the linked .exe, so every common control (buttons, list views, edit boxes…) rendered in the unthemed Win95/classic style regardless of the OS theme. This embeds a Win32 manifest declaring the Microsoft.Windows.Common-Controls v6 side-by-side dependency, which activates visual styles (the Fluent look) on Windows 10/11.

DWM (#4682) modernizes the frame; this modernizes the controls. Together they close most of the visual gap on the existing Win32 backend.

Changes

• New windows_app.manifest — comctl32 v6 dependency + an asInvoker execution level (declaring it explicitly keeps UI binaries out of the UAC installer-detection heuristic).
• Link step writes the manifest to a temp file and passes /MANIFEST:EMBED /MANIFESTUAC:NO /MANIFESTINPUT:<path>. Both link.exe and lld-link embed /MANIFESTINPUT: content via /MANIFEST:EMBED with no external mt.exe/rc.exe, so this works on the MSVC path and the cross-from-mac lld-link path alike. /MANIFESTUAC:NO suppresses the linker's auto-generated UAC fragment so it can't emit a second trustInfo block alongside ours.
• Gated on ctx.needs_ui so console-only binaries stay manifest-free.
• Hoisted the manifest to a pub(super) const WINDOWS_APP_MANIFEST and added regression tests guarding the v6 dependency, public key token, and asInvoker level.

Why not DPI in the manifest

This manifest deliberately does not declare dpiAware/dpiAwareness. Perry sets DPI awareness at runtime via dpi_compat (issue #303, to keep Win7 startup working and choose per-monitor-v2); a manifest declaration would conflict with that path. DPI stays out of scope here.

Testing

• cargo test -p perry --bin perry windows_link_tests — 7 passed (5 existing subsystem guards + 2 new manifest guards).
• cargo check -p perry clean; cargo fmt clean.
• The runtime-if is_windows link branch compiles on the macOS host (not cfg-gated), so the embed code is type-checked here. The actual embedding + control theming needs a Windows runner / manual smoke before merge — confirm dumpbin /manifest (or Resource Hacker) shows the Common-Controls v6 dependency in a built UI .exe and that the ToDo sample renders themed controls.

Part of #4681, discussion #3486.

[proggeramlug]

Lint fix + Windows smoke verification ✅

Lint failure was the 2000-line file-size gate — the manifest additions pushed link/mod.rs to 2038 lines. Fixed by extracting WINDOWS_APP_MANIFEST + the embed logic into a sibling link/windows_manifest.rs (embed_app_manifest(cmd, needs_ui)); mod.rs re-exports the const so windows_link_tests still reaches it. No behavior change. mod.rs is now 2000 lines and scripts/check_file_size.sh passes.

Verified on a real Windows build (host: Windows 11, lld-link, MSVC 14.50 toolchain) — this is the smoke the PR description flagged as still needed:

• Built perry + perry-ui-windows release, compiled test-files/test_issue_442_inline_button_bg.ts (a perry/ui app).
• mt.exe -inputresource:app.exe;#1 extracted the embedded manifest:

  <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
    version="6.0.0.0" processorArchitecture="*"
    publicKeyToken="6595b64144ccf1df" language="*"/>
  ...
  <requestedExecutionLevel level="asInvoker" uiAccess="false"/>

  → Common-Controls v6, correct public key token, and a single trustInfo/asInvoker block (no duplicate — /MANIFESTUAC:NO did its job).
• needs_ui gate confirmed: a console-only program (console.log) produced an exe with no resource section (mt.exe reports "did not contain a resource section") and ran correctly.

cargo test -p perry --bin perry windows_link_tests → 7 passed.

[proggeramlug]

Rebased onto latest main to clear the merge conflict in windows_link_tests.rs (main's windows_subsystem_needs_ui tests landed in the same region — kept both test sets).

Also note: main had since grown link/mod.rs by a few lines, so the extract-to-sibling refactor now also moves the Windows system-library link line into the new module (renamed link/windows_manifest.rs → link/windows_link.rs, exposing add_system_libs + embed_app_manifest). mod.rs drops to 1966 lines — comfortable headroom under the 2000 gate instead of sitting right at it. Link args emitted are byte-identical; windows_link_tests → 11 passed (5 existing + 4 main's subsystem + 2 manifest).