Generate the TLS certificates in process

gen-dev-cert.sh is gone. The server ensures its own certificates on start,
which removes a setup step to remember, a dependency on whatever openssl
was installed, and a second place for the "which addresses?" answer to
live -- the leaf now covers every local IPv4 plus loopback and the
emulator's host alias, so nobody maintains a hardcoded IP.

The split that mattered in the script is kept and now enforced by tests:
the CA is generated once and left alone, because the app pins it and
replacing it strands every installed copy; the leaf is cheap and reissued
every start, so covering a new address is a restart. Both are written
owner-only into a directory outside the repo.

Two things the tests caught. DirBuilder's mode applies only when the
directory is created, so a directory that already existed kept whatever
permissions it had while holding a private key -- the mode is now set
explicitly, in the session directories too. And loading the leaf into the
real RustlsConfig needs the crypto provider installed, which main does but
tests don't.

Verified end to end: deleted the certs, started the server, watched it
generate a CA and warn that installed apps now pin the wrong one, rebuilt
the APK against the new CA, and reinstalled -- the emulator connects over
a certificate that never existed as a pasted constant.

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

AGENTS.md

@@ -40,10 +40,11 @@ repo is in PLAN.md's "Backend layout" section.
   `when`; `Api.kt`/`EventStream.kt` the REST + SSE clients; `Events.kt` the
   event model mirror; `ServerConfig.kt` settings + Keystore-sealed token;
   screens in `SessionListScreen/SessionScreen/SpawnScreen/SettingsScreen`.
-- `gen-dev-cert.sh` / `certs/` — copied from local-updater's scheme
-  (idempotent CA, reissued leaf; regenerating the CA strands the installed
-  app — same one-way door). Dev SANs cover 127.0.0.1, 10.0.2.2 (emulator →
-  host), and the LAN IP alongside the WireGuard address.
+- `server/src/certs.rs` — the TLS certificates, generated in process on
+  first start into `$XDG_CONFIG_HOME/ai-app/certs`: idempotent CA, leaf
+  reissued every start covering every local IPv4 plus 127.0.0.1 and
+  10.0.2.2 (emulator → host). Regenerating the CA strands the installed
+  app — the one-way door.
 
 ## Status
 
@@ -65,7 +66,7 @@ real-phone/WireGuard bring-up, which is operational rather than code.
   on the emulator.
 - **The APK pins the CA of the machine that builds it**, read at build time
   from `$XDG_CONFIG_HOME/ai-app/certs/ca.pem` (`AI_APP_CA` overrides) and
-  generated into a constant. So `./gen-dev-cert.sh` must have run on that
+  generated into a constant. So the server must have started once on that
   machine first — the build stops with that instruction otherwise — and an
   APK built in this VM only works against a server in this VM.
 - Run the server for development with `--bind 127.0.0.1` (wg0 doesn't exist
@@ -122,9 +123,11 @@ Established 2026-08-25, and it decides more than it looks like:
   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.
-- 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
+- Certificates are generated **by the server, on first start**, into
+  `$XDG_CONFIG_HOME/ai-app/certs` (`--certs` overrides). The CA is created
+  once and then left alone; the leaf is reissued every start, so covering a
+  new address is a restart. Starting the server in the VM therefore makes a
+  separate throwaway dev CA for emulator work — never install a build
   pinning that on the real phone.
 - Point development at a scratch state directory rather than the real one:
   `--config /tmp/…/config.json --data-dir /tmp/…/sessions --port 8444`, or