feat: add local VM workflow and opt-in dubuntu agents

[rhnvrm]

Why this MR

We wanted to develop and test Dummie end to end on one NixOS machine: run the control plane locally, enroll a VM host, create a guest through the API or console, reach it over SSH and the browser console, and use pi and Codex inside dubuntu through Dummie's LLM proxy.

Trying that flow exposed several gaps. Building a kernel and setting up tap/NAT made the host expensive and cumbersome to start. The local proxy needs high ports, but VM URLs and the login callback assumed ports 80/443. The browser and QEMU host reach the same object store at different addresses. Finally, dubuntu needed agent configuration for the internal model proxy without baking a local-only domain into a generic or production image. This MR records the working local path and the fixes found while exercising it.

What changed

• DEV.md and docker-compose.local.yml set up PostgreSQL, ClickHouse, RustFS, the control server, and the website for local development. LOCAL_VMS.md walks through host enrollment, a small guest, SSH, browser access, dubuntu, and the local Vector settings that ship host usage logs to ClickHouse.
• An opt-in qemu-local launcher uses packaged host and guest kernels, QEMU user networking, a persistent disk, and a loopback artifact server. vm-local-* recipes operate it; the existing qemu-host, tap networking, and vm-* recipes keep their previous behavior. An archive based kernel source recipe is optional.
• The control API adds the configured local proxy port to VM and console URLs. dproxy preserves that port through the browser login callback while still checking tokens against the normalized VM hostname. LOCAL_VM_SSH_PORT also tells the VM page to copy an SSH command with the forwarded local port; production keeps the default port 22.
• S3_HOST_ENDPOINT lets dclient receive presigned kernel and rootfs URLs for the QEMU gateway while browser downloads keep using S3_PUBLIC_ENDPOINT. Without the new setting, host downloads use the existing public endpoint.
• dubuntu installs Codex and bundles a Dummie pi extension. just image-build-local-dubuntu enables both agents against the local LLM proxy. Generic builds leave the Dummie provider unconfigured; a fleet build can supply its own domain and proxy URL.

How to review and try it

Start with DEV.md and LOCAL_VMS.md for the intended flow. The implementation is grouped in justfile/nix-vms, the control URL and S3 code, dproxy auth, and the dubuntu image. The local values live in ignored env and artifact files; no enrollment key or model credential is included in the image or this MR.

For a local smoke test, follow the two guides, then run just vm-local-start, enroll the host, and create an Alpine or dubuntu VM. just vm-local-ssh reaches the host; just vm-local-proxy-tunnel exposes guest SSH and browser access on local ports.

Verification and limits

• Focused control tests for S3 endpoint selection and local VM URLs pass. Focused dproxy redirect and callback tests pass.
• Both Nix launchers build. Their generated commands retain tap networking for qemu-host and use user networking for qemu-local.
• Docker's dubuntu build check, Compose config check, Just parsing, and git diff --check pass. The migrated local QEMU disk boots with SSH and dclient active; pi and Codex were exercised against the local proxy during development.
• With PR 3's metering changes temporarily applied, the local QEMU host reached ClickHouse at 10.68.0.1:8123; dclient installed Vector 0.57.0, and its ClickHouse sink passed its health check. A dubuntu LLM request then appeared automatically in the personal usage report with its VM name and estimated cost.
• The previous UI command reached this development machine's own SSH server on port 22. With the local tunnel on 2224, ssh -p 2224 dubuntu-test@dummie.localhost authenticated with the account's saved public key and reached the guest as ubuntu. The VM API now returns ssh_port: 2224 for the UI; the port is omitted in production.
• Full go test ./... suites were red on both base main (9d0d074) and the earlier MR revision (b030834). The five control failures and four dproxy failures had identical test names on both revisions; they are addressed separately in PR 2. Focused tests for the changed behavior pass.