Windows executor backend: decide whether winget support is in scope, and implement OS capability selection if so

[sabbour]

Problem

The sandbox capability contract (added in #757, packages/Agentweaver.SandboxExec/SandboxCapabilities.cs)
reports winget as UnsupportedOnPlatform with the remediation "requires a Windows executor
backend". That answer is honest and tested, but it is currently the end of the story: there is no
Windows executor, so any product requirement that depends on winget cannot be met.

winget is the Windows Package Manager. It is a Windows-only executable and cannot run under the
Linux Kata guest, under Wine, or through any emulation we would be willing to trust. This is not a
missing feature of our sandbox — it is an OS boundary.

What this issue covers

Decide and then implement one of:

Option A — accept the limitation. winget is not part of the product contract. The capability
response already explains this clearly and is covered by
tests/Agentweaver.Tests/Sandbox/SandboxCapabilityContractTests.cs. Close this issue with that
decision recorded. Agents asking for Windows package installation get a precise, actionable answer
(apt-get on Linux) rather than a confusing failure.

Option B — add a Windows executor backend. Required if the product genuinely needs winget.
Sketch of the work:

• An additional sandbox pod template targeting a Windows node pool (AKS Windows Server node pool;
  note that Kata does not run Windows containers — the isolation story would be Hyper-V isolated
  containers or a dedicated node pool, and that trade-off needs its own security review).
• A Windows implementation of the executor sidecar. The current one relies on Linux user namespaces,
  bubblewrap, overlayfs, and process groups; none of these have direct Windows equivalents. The
  likely substitutes are job objects, AppContainer/low-privilege service accounts, and per-run
  directories with ACLs.
• OS capability selection in the scheduler: a run declares (or infers) the OS it needs, and the
  warm pool for that OS serves it. The capability contract is already the natural discovery surface.
• Its own real integration evidence, on the same standard as fix(sandbox): unblock AgentHost warm pool on real AKS Kata with a hardened executor sidecar #757: process/mount isolation,
  cross-run isolation, no credential exposure, fail-closed readiness, cleanup.

Recommendation

Option A unless a concrete user requirement appears. Option B is a large, separately reviewable
piece of platform work with its own isolation model, and it should not be started implicitly.

Current behaviour (already shipped in #757)

winget  UnsupportedOnPlatform
        "winget is the Windows Package Manager and cannot run on the Linux Kata guest.
         Use apt-get for Linux packages; Windows package installation requires a
         Windows executor backend, which this deployment does not provide."

This is asserted by test, so the contract cannot silently drift into claiming support.

[github-actions]

🔄 Ralph — Auto-Triage

Assigned to: Tank
Reason: Matched backend/API role keywords
Source: role-keyword

Ralph auto-triaged this issue using routing rules.
To reassign, swap the squad:* label.

[github-actions]

🔄 Ralph — Auto-Triage

Assigned to: Tank
Reason: Matched backend/API role keywords
Source: role-keyword

Ralph auto-triaged this issue using routing rules.
To reassign, swap the squad:* label.