WireGuard bring-up: host setup script, in-VM test tunnel, portable repo_root

wg-setup-host.sh sets up the tunnel on the backend host: keys generated
there and kept there, wg0.conf, wg-quick enabled, and the phone's config
printed as a scannable QR. Split tunnel (AllowedIPs is only the backend
subnet), single-address addressing per PLAN.md, and the three things it
can't do for you -- router UDP forward, DDNS, hairpin check -- spelled
out at the end.

test-wg-tunnel.sh stands up a real WireGuard tunnel between two network
namespaces inside one machine, so the production posture (bind wg0 and
nothing else) is testable with no router, phone, or internet exposure.
Verified: real handshake, server listening on 10.66.0.1:8443 only, and
an authorized request from inside the tunnel answering 200 over pinned
TLS -- the leaf's 10.66.0.1 SAN is what a phone will validate too.

repo_root() now resolves from the running executable before falling back
to the compiled-in path: the repo is shared host<->VM over virtiofs at
different absolute paths with a shared target/, so a binary built on one
side and run on the other looked for its config where nothing exists.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw

AGENTS.md

@@ -70,6 +70,38 @@ real-phone/WireGuard bring-up, which is operational rather than code.
   `adb shell "am start -a android.intent.action.VIEW -d 'aiapp://enroll?host=10.0.2.2&port=8443&token=…'"`
   (quote so the device shell doesn't eat the `&`s).
 
+## Where things run (host vs this VM)
+
+Established 2026-08-25, and it decides more than it looks like:
+
+- **The host (192.168.1.168) is the backend machine.** It runs
+  local-updater's server today and is where `ai-server` belongs in
+  production: it has the LAN address the phone can reach, and it's where
+  WireGuard terminates. `wg-setup-host.sh` sets that up (keys, `wg0.conf`,
+  the phone's QR); run it there with `sudo WG_ENDPOINT=<ddns name>`.
+- **This VM is a dev sandbox behind qemu user-mode networking**
+  (10.0.2.15, gateway 10.0.2.2) — outbound only. The host is reachable at
+  10.0.2.2, but **nothing outside can initiate a connection into the VM**,
+  so the tunnel and the real phone can never terminate here.
+- The repo is the *same files* on both sides over virtiofs, at different
+  absolute paths: `~/host/repos/ai-app` in the VM,
+  `~/stuff/vm/ai/repos/ai-app` on the host. `server/target/` is shared
+  along with it, so **a `cargo build` on one side replaces the other's
+  binary** (and each rebuilds from scratch after the other). `repo_root()`
+  resolves from the running executable for exactly this reason — a
+  host-built binary run in the VM used to look for its config under a path
+  that doesn't exist here.
+- `wg0` (10.66.0.1) now exists in this VM too, so the production path —
+  `ai-server` with no `--bind` — is exercisable during development. It has
+  no reachable peer and doesn't need one; the interface existing is what
+  the server requires. Consequence: **with no `--bind`, the emulator can't
+  reach the server** (it dials 10.0.2.2), so keep using
+  `--bind 127.0.0.1` for app work.
+- `./test-wg-tunnel.sh up|test|down` builds a real tunnel between two
+  network namespaces inside one machine and drives the server through it
+  — a genuine handshake against 10.66.0.1 with pinned TLS, no router or
+  phone involved. That's the way to verify the wg0-only posture.
+
 ## Things that have bitten
 
 - **tracing caches callsite interest process-wide.** A test that hits a