Drop the in-repo state fallback

Nothing has run against the host's backend yet, so there is no old config
or transcript to keep working -- the XDG paths are simply where state
lives. Removing the fallback takes repo_root() with it, since finding the
repo from the running executable existed only to locate that legacy state.

AGENTS.md gets the arrangement that replaced it: the host builds and runs
from its own clone outside the shared mount, and code reaches it by push
to gitea, which this VM's key is not authorized for.

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

AGENTS.md

@@ -83,14 +83,19 @@ Established 2026-08-25, and it decides more than it looks like:
   (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.
+- **Code reaches the host through gitea, not the shared mount.** This VM's
+  checkout (`~/host/repos/ai-app`, a virtiofs mount the host also sees at
+  `~/stuff/vm/ai/repos/ai-app`) is a working copy only: its `origin` is
+  `git@git.arirex.me:iris/ai-app`, and the VM's key is **not** authorized
+  for it — pushing from here fails with `Permission denied (publickey)`.
+  The host pushes, and its own separate clone — outside the shared mount —
+  is what gets built and run. So the review at push time, not a filesystem
+  permission, is what keeps VM-authored code off the host.
+- Consequence for building here: `server/target/` is shared with the host's
+  view of *this* checkout, so if anything on the host ever builds from the
+  shared path, the two `cargo build`s replace each other's binary and each
+  rebuilds from scratch. Building on the host from its own clone avoids it
+  entirely.
 - `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
@@ -109,9 +114,7 @@ Established 2026-08-25, and it decides more than it looks like:
 - **Nothing secret goes in the repo.** The VM is treated as untrusted (see
   PLAN.md's security section), and the repo is shared read-write with the
   host, so state lives outside it: `$XDG_CONFIG_HOME/ai-app/config.json`
-  and `certs/`, `$XDG_DATA_HOME/ai-app/sessions/`, owner-only. The server
-  still reads a pre-move `config.json`/`sessions/` from the repo, with a
-  warning, so an old install keeps working.
+  and `certs/`, `$XDG_DATA_HOME/ai-app/sessions/`, owner-only.
 - Certificates are generated **on the machine that serves them**
   (`./gen-dev-cert.sh`, honours `AI_APP_CERTS`). Running it in the VM makes
   a separate throwaway dev CA for emulator work — never install a build