Runner setup on macOS: release, test the needs, decide on a bundled vfkit #200

Desktop 0.3.9 wasn't built for macOS, because DESKTOP_MACOS_RUNNER is unset and there's no Mac to build on.

1. Once a Mac runner exists, release the macOS app (ask the owner before cutting a release).
2. Test the homebrew, vfkit and macos_update needs on Apple silicon and on Intel, screenshotting each state from the real app.
3. Decide whether to ship a signed vfkit with the runner, so that no Homebrew is needed. That touches signing and the virtualization entitlement, so write up the tradeoff for the owner.

This item is blocked until a macOS runner is available.

Background: guided runner setup (shipped 2026-10-15, #142)

Anyone who installs the desktop app on a clean computer should get its runner running Linux jobs and Windows jobs (and later macOS jobs) without knowing what WSL, Hyper-V, virtualization or Docker are. Read apps/docs/src/content/docs/guides/desktop.md, "Getting the runner running".

How it works (g1t-runner 0.3.5, desktop 0.3.9):

• g1t-runner sandbox status --json gives each capability its needs, whatever must come first listed first: restart, windows_update, virtualization, nested_virtualization, vm_platform, wsl, wsl_update, windows_edition, windows_sandbox, kvm_module, kvm_group, qemu, macos_update, homebrew, vfkit (crates/runner/src/selfhosted/needs.rs). A need is named only when the computer says so for certain. Windows facts come from one PowerShell CIM probe and are kept in the state folder's windows-facts.json until Windows restarts. Set up's restart is the state folder's restart-pending, which holds the boot it was written in.
• The app's words for each need are in diagnosis.rs need_words. Set up (apps/desktop/src-tauri/src/runner/setup.rs) runs one fixed PowerShell script as -EncodedCommand through ShellExecuteExW "runas". The script turns on VirtualMachinePlatform and Containers-DisposableClientVM, and runs wsl --install --no-distribution / wsl --update (--web-download first). Exit code 3010 means a restart is needed. Restart now asks with a native MessageBox, and RunOnce reopens g1t after the restart.
• The cards for each kind of job are independent. Whole-runner code is NeedsSetup.

Already verified: the published 0.3.5 runner on the owner's PC (no needs), the elevated script with nothing to do (UAC, then Done), the script unelevated (fails plainly and changes nothing), its WSL step (--version), the fixture scenario tests, and the rendered Runner window and docs.

Rules (non-negotiable)

• Runner jobs run in host-proof sandboxes. Docker and running directly on the computer are only ever the person's choice, never a fallback.
• The app must stay responsive: never block the main thread, and never hold a lock across a Tauri menu or window call (that froze 0.3.7).
• Never restart the owner's PC or toggle its Windows features without the owner's OK for that specific restart. Use VMs.
• Ask before cutting any desktop or runner release. A release means: bump version (crates/runner/Cargo.toml, apps/desktop/src-tauri/Cargo.toml), merge, and push runner-v<version> / desktop-v<version> to the g1t remote. The workflows refuse a tag whose version doesn't match Cargo.toml.
• On Windows, run cargo from PowerShell, not Git Bash (it needs the VS Build Tools C++ toolchain). The target directories are shared: target/ at the root for the runner, and apps/desktop/src-tauri/target for the app.

Validation for every change

cargo test -p g1t-runner; in apps/desktop/src-tauri, cargo test and cargo clippy --all-targets; the ignored live tests where they apply (cargo test -- --ignored this_windows, the_script_runs, the_wsl_step; as_administrator needs a UAC click); docs rendered with astro dev. Report what was verified on real machines and what was verified only in fixtures.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.