Track Windows 10 support: bootstrap the framework without Windows 11-only imports #8

The GUI executable does not start on Windows 10 (#7): the loader stops with "无法定位程序输入点 TryCreatePackageDependency" before main runs. This issue tracks the work to support Windows 10 and other builds before Windows 11 24H1.

Cause

Windows App Runtime 2.x itself supports Windows 10 1809 and later. Every installed Microsoft.WindowsAppRuntime.2 package (2.2.0–2.5.1) and the 2.5.1 DDLM package declare MinVersion="10.0.17763.0".

The blocker is windows-reactor's framework bootstrap (crates/libs/reactor/src/native/bootstrap.rs):

• It calls the Windows 11 dynamic dependency API (TryCreatePackageDependency, AddPackageDependency). The API reference lists Windows 11 (10.0.22000) as the minimum. The dynamic dependency guide says unpackaged apps must reference the Windows App SDK framework through the bootstrapper API.
• Both functions are imported statically from api-ms-win-appmodel-runtime-l1-1-5.dll (confirmed with dumpbin /imports on the 0.1.4 release build). On Windows 10 the process therefore fails at load time, which also takes down CLI mode and the runtime check dialog.
• Upstream: windows-reactor commit 5419f50 breaks framework-dependent apps on Windows builds below 22000 microsoft/windows-rs#4866 and windows-reactor on Windows 10 microsoft/windows-rs#4924 report the same failure. Both were closed without a code change; the maintainer suggested self-contained deployment plus /DELAYLOAD. bootstrap.rs on upstream master is unchanged.

nyanpasu-windows-dependencies (df7fa8f) is not affected. It detects runtimes through WinRT PackageManager.FindPackagesByUserSecurityIdPackageFamilyName, which works on Windows 10.

Fork change (d1574fd on nyanpasu, released in v0.1.5)

The change mirrors the gate in Windows App SDK's own bootstrapper (dev/DynamicDependency/API/MddWin11.h, IsWindows11_24H1OrGreater):

• Windows 11 24H1 and later (kernelbase.dll exports TryCreatePackageDependency2): use the OS dynamic dependency API, now resolved with GetProcAddress instead of being imported statically.
• Earlier builds: load Microsoft.WindowsAppRuntime.Bootstrap.dll from the executable's directory only (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_SYSTEM32) and call MddBootstrapInitialize2(0x00020005, NULL, 2.5.1.0, None). When neither the framework nor the DDLM package matches, the bootstrapper returns STATEREPOSITORY_E_DEPENDENCY_NOT_RESOLVED, so the existing install dialog still applies.
• run_with now initializes COM (STA) before bootstrapping, because the bootstrapper reaches the DDLM out-of-process server through COM.
• bindings.txt is updated and bindings.rs regenerated with tool-reactor. app/mod.rs now uses the generated GetModuleHandleW instead of its own declaration. docs/crates/windows-reactor.md documents the bootstrapper requirement.

Behavior change: Windows 11 22H2 and 23H2 also take the bootstrapper path, as they do in Windows App SDK's own bootstrapper.

Verified so far (Windows 11 26300 x64)

• Clippy for windows-reactor (--features test --all-targets -D warnings) passes. cargo test for enable-loopback passes (53 tests).
• The release import table no longer references api-ms-win-appmodel-runtime-l1-1-5.dll.
• The default (OS API) path starts the GUI and loads the table.
• With the gate forced to fail:
  • Without Bootstrap.dll, the GUI shows "Could not load Microsoft.WindowsAppRuntime.Bootstrap.dll beside the executable … (0x8007007E)".
  • With Bootstrap.dll (x64, Microsoft.WindowsAppSDK.Foundation 2.3.12, the Foundation version pinned by Windows App SDK 2.5.1), the process loads it and the WinUI window renders.
  • On this build the bootstrapper uses the OS API internally, so this run checks DLL loading, the call ABI and COM order. It does not exercise the DDLM path.

Remaining work

• Commit the fork change on nyanpasu (d1574fd), add it as patch 8 in Track windows-reactor gaps patched in our windows-rs fork #2, and bump the submodule (Load on Windows 10: bootstrap the framework without Windows 11-only imports #9)
• Ship Microsoft.WindowsAppRuntime.Bootstrap.dll for the process architecture beside enableLoopback.exe. Since v0.1.5 the release workflow publishes it (Publish the Windows App SDK bootstrapper with each release #10), taken from runtimes/win-{x64,arm64}/native/ in Microsoft.WindowsAppSDK.Foundation 2.3.12 (x64 ≈ 385 KB, imports only system DLLs and UCRT, no VC++ redistributable). clash-nyanpasu bundles it in feat(windows): bundle the Windows App SDK bootstrapper with enableLoopback clash-nyanpasu#6043 (draft)
• runtime_check: on builds without TryCreatePackageDependency2, also check the DDLM package Microsoft.WinAppRuntime.DDLM.2.5.1.0-{x6,a6} and the presence of Bootstrap.dll, so the localized dialog handles these cases before reactor's English fallback
• Check whether the Microsoft Store install provides the DDLM package on Windows 10. The official installer does; a Windows 11 26300 machine has no 2.x DDLM installed
• Test on a real Windows 10 22H2 (19045) x64 machine, and on Windows 11 22H2/23H2, which now use the bootstrapper
• Update docs/design.md (§1 item 4, §8.1); the README runtime requirements were updated in Load on Windows 10: bootstrap the framework without Windows 11-only imports #9 and Publish the Windows App SDK bootstrapper with each release #10
• Separately: scripts/gui-smoke.ps1 fails at Missing header Display name ▲ on the 0.1.4 debug build as well; the assertion predates the sort-glyph change

Refs #7, #2.