fix(supervise): reach the queue over RPC, get bot-bottle.db off the data plane

PRD 0070's rule — only the orchestrator opens bot-bottle.db; the data
plane reaches state through the control-plane RPC — was not in force.
Three data-plane daemons held a direct read-write handle on the shared
SQLite file: the supervise MCP server, the egress DLP addon (the most
attack-exposed process, TLS-bumping hostile traffic), and the git-gate
pre-receive hook. An RCE in any of them could read every bottle's
plaintext identity_token and forge attribution fleet-wide (issue #469).

Add the agent half of the supervise flow to the control plane:

  POST /supervise/propose  -> queue a proposal, 201 {proposal_id}
  POST /supervise/poll     -> non-blocking decision poll, 200 {status,...}

Both attribute the caller by (source_ip, identity_token) exactly like
/resolve — never a caller-supplied slug — so a bottle can only ever queue
or read its own proposals even if the data plane is compromised. A decided
poll archives server-side, preserving the archive-after-read contract.

Data plane: the supervise server, egress addon, and git-gate hook now
queue/poll through PolicyResolver.propose_supervise / poll_supervise
instead of opening the DB. supervise_server keeps its ~30s grace window
by polling the RPC; egress keeps its safelist keyed by resolved bottle;
the git-gate hook gets (source_ip, identity_token) from the CGI env.

Packaging: drop the DB bind-mount and SUPERVISE_DB_PATH from the
data-plane containers/VMs (docker gateway + infra, macOS infra,
firecracker infra). The orchestrator remains the sole opener of the one
file via BOT_BOTTLE_ROOT / host_db_path().

Update PRD 0070: the rule is now in force; remove the transitional caveat.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/prds/0070-per-host-orchestrator.md

@@ -299,11 +299,14 @@ and integrate a console against.
   the data plane and the console reach state through the control-plane RPC,
   never a direct file handle.** No agent-facing component gets the file, so
   none can forge attribution. (This supersedes the earlier `ro`-mount idea.)
-  - *Transitional caveat:* today the per-bottle **supervise gateway
-    rw-bind-mounts `bot-bottle.db`** to write proposals — exactly the
-    pattern the orchestrator removes (supervise consolidates into the
-    orchestrator; gateway writes become RPC calls). Until that lands, don't
-    put the attribution registry behind a data-plane-writable mount.
+  This rule is now **in force** across the data plane (issue #469): the
+  supervise daemon, the egress addon, and the git-gate pre-receive hook queue
+  proposals and poll for their responses over the agent-side supervise RPC
+  (`POST /supervise/propose` + `POST /supervise/poll`, attributed by
+  `(source_ip, identity_token)` exactly like `/resolve`), so a bottle can only
+  ever queue or read its own proposals. The gateway/data-plane containers no
+  longer bind-mount the DB directory or carry `SUPERVISE_DB_PATH`; the
+  orchestrator is the sole opener of the one file.
 
 Implementation note for the VM slices: SQLite **WAL** over a guest share
 (virtiofs/9p) is finicky (the `-shm`/`-wal` files need real mmap/locking),