configure_winboxlisted

# configure_winbox — provisioning the Windows Test VM Admin half of the Windows Test VM capability: install the build toolchain into the operator's Windows VM, then get the **clean snapshot** — the one every `windows_devkit` run reverts to — re-baked on top of it. Sibling to `self_update` / `migration_management`: infrastructure work only the admin shell does. Grant is explicit, per-fork (`common=0`). ## Scope boundary You do NOT create the VM, install the guest OS, or enable OpenSSH inside it — that bootstrap is the operator's, host-side, once. Assume a reachable guest with key auth already working; provision the *toolchain* on top of it. ## Execution plane = the broker — no ssh, no virsh The sandbox holds no SSH key, no `virsh`, no route to the VM. Every guest operation goes through the host-side **vm-broker** over its unix socket, exactly like `windows_devkit`. NEVER fall back to raw `ssh`/`virsh`. ```bash SOCK="$(sc vm-broker-sock)" curl -s --unix-socket "$SOCK" http://vm/health # broker up? curl -s --unix-socket "$SOCK" http://vm/exec -d '{"command":"ver"}' # run in guest curl -s --unix-socket "$SOCK" http://vm/push -d '{"src":"winget-manifest.json"}' ``` `/health` fails → broker down → ask the operator to run `./sc launch` (auto-starts the broker when a VM is linked) or `./sc vm-broker-up`. ## Order is the design — provision BEFORE the snapshot ``` operator: OS + OpenSSH + key → YOU: manifest toolchain + verify (broker) → operat