Retire native Windows Prime runtime paths in favor of WSL2 #222

Problem

Prime Agent does not currently support native Windows as a product runtime, and the supported Windows route for Pylon maintainers is WSL2. Pylon PR #201 nevertheless added native-Windows package-wrapper and environment/home handling while proving background generation on a Windows host. That is premature maintenance scope and can imply support we do not offer.

The parity audit attributes 293 added lines to this native-only surface (163 production and 130 direct tests; a stricter literal-branch lower bound is 248). The other provider reliability work remains Linux/WSL2/macOS or provider-neutral and must not be disturbed.

Scope

• make native win32 Prime provider execution explicitly unavailable with actionable WSL2 guidance;
• do not start Prime daemon, ACP, background-generation, capacity, catalog, install, or update processes natively on Windows;
• remove native .cmd/.ps1 Prime package discovery and native Windows environment/home branches added by feat(server): add isolated Prime background writing #201;
• remove only the direct native-runtime tests and hosted native provider row;
• retain generic package containment/archive safety and Windows desktop packaging, because a Windows client can connect to a WSL2-hosted environment;
• retain ACP degradation on supported Linux/macOS/WSL2 runtimes;
• document that native support can be reconsidered only after upstream Prime supports Windows.

Acceptance

• native Windows reports one truthful unavailable state and launches zero Prime processes;
• UI/docs direct users to WSL2 without advertising a native ACP fallback;
• Linux, macOS, and WSL2 use the existing public SDK/detached-daemon path unchanged;
• Windows desktop build/package checks remain green and are not confused with provider-runtime support;
• focused tests prove the platform gate across status, interactive start, and background generation;
• at least one non-Prime provider remains unchanged.

Part of #114. The distribution/install/multi-instance trackers #193, #194, and #199 already use this WSL2-only scope.