docs(readme): container-tier missions no longer hold provider keys

LLM proxy enabled on prod and proven on mission 01a0cf7e: container env and
config hold only cmlp tokens (no real key value anywhere in either), both
fallback hops rewritten, the mission completed, judged MET and pushed. Controls:
no token 401, forged 401, finished mission 403, port unreachable from outside.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

README.md

@@ -229,6 +229,7 @@ source file. It is **not currently run in CI**, and 12 files exceed the hard lim
 
 **Next**
 - Enforce task permission and argument provenance (both still in shadow, gathering evidence).
+- Route microVM missions' model calls through the LLM proxy too, so no guest holds a provider key.
 - Evidence the remaining team templates (4 of 12 still need a target stack: mobile, gpu, threejs, and
   `insight_research`).
 - A dedicated judge key, so no other consumer of a shared provider plan can starve the judge.
@@ -254,13 +255,14 @@ structures, never gives an agent more reach than its sandbox. What that means to
   [`docs/TASK-PERMISSION-AND-TAINT.md`](docs/TASK-PERMISSION-AND-TAINT.md) for the measurements and the
   controls being built on top.
 - Platform credentials are held by the secret broker behind a private socket, and a mission container
-  gets only a narrowly scoped skills token, never a ClawMates session. **Model-provider keys are the
+  gets only a narrowly scoped skills token, never a ClawMates session. **Model-provider keys never enter
-  exception:** Claude Code inside a mission needs its own credential, so container-tier missions carry
+  a container-tier mission** when the LLM proxy is on (`CLAWMATES_LLM_PROXY=1`, as on prod): the
-  the provider keys (`CLAUDE_CODE_OAUTH_TOKEN`, and `ZAI_API_KEY` / `KIMI_API_KEY` for the fallback
+  container holds a per-mission token, Claude Code's base URL points at the server's proxy on an
-  chain) in their environment, readable by the agent. What limits the damage: delivery refuses to push
+  unpublished port, and the proxy adds the real credential — honouring the token only while its mission
-  any change containing one of those keys (exact values, verbatim or base64), and every recorded event,
+  is running. Behind that, delivery refuses to push any change containing a server key, and every
-  judge verdict and judge input is redacted before it is stored or sent. A key sent straight to a host
+  recorded event, judge verdict and judge input is redacted. MicroVM missions still receive their
-  over the network is not covered yet. The server reaches Docker through an allow-listed socket proxy.
+  backend's key in the guest, behind the egress allow-list. The server reaches Docker through an
+  allow-listed socket proxy.
 - The gate is a guardrail against accidents and obvious exfiltration, not a boundary against a
   determined agent (indirection defeats string matching). The boundaries are the VM, the network policy
   and the broker.