feat(smolmachines): patch smolvm state DB to actually enforce per-bottle allowlist

Earlier commit framed this PR as "infrastructure landed, TSI
enforcement blocked on upstream smolvm 0.8.0." Found a clean
workaround that lets us enforce now.

Smolvm persists each machine's config (including
`allowed_cidrs`) as a JSON BLOB in
`~/Library/Application Support/smolvm/server/smolvm.db`,
`vms.data`. `machine create --allow-cidr X/32` silently writes
`allowed_cidrs: null` to that row when combined with `--from`,
but smolvm reads the row at `machine start` — so patching the
row between create and start sets the allowlist for real.

New `loopback_alias.force_allowlist(machine_name, cidrs)` opens
the SQLite DB, JSON-decodes the row, sets `allowed_cidrs`, and
writes back as BLOB (Text type silently corrupts smolvm's
later reads). launch.py calls it immediately after
`machine_create` and before `machine_start`.

Verified end-to-end on macOS / Docker Desktop:

  VM allowlist after start: ["127.0.0.16/32"]
  VM → 127.0.0.1:3000      → BLOCKED (Permission denied)
  VM → 8.8.8.8:53          → BLOCKED (Permission denied)
  VM → 127.0.0.16:<bundle> → CONNECTED

The DB-patch hack is correct only because smolvm reads
`allowed_cidrs` from the row at start time (not derived in-
process). When upstream honors `--allow-cidr` with `--from`,
the call becomes redundant — drop the call and the workaround
is gone.

Tests: 4 new for `force_allowlist` (BLOB round-trip; Linux
no-op; missing DB; missing row). Total 593 unit tests pass.

README + PRD updated to reflect the fix landed (no longer
"infrastructure pending upstream"). gitea#75 can close.

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

README.md

@@ -205,21 +205,20 @@ each reserve a loopback alias from a pool (`127.0.0.16` ..
 `127.0.0.31`) and bind their bundle's port-forwards to it; the
 first `./cli.py start` after each reboot prompts for sudo to add
 missing aliases via `ifconfig lo0 alias`. Aliases persist until
-reboot; subsequent launches don't prompt.
+reboot; subsequent launches don't prompt. The agent's TSI
+allowlist is the alias's `/32`, so each bottle can only reach
+its own bundle's published ports — not other bottles' ports,
+not other host loopback services (postgres, dev servers, etc.).
 
-**Known v1 limitation — agent can reach the whole host
-loopback:** the alias-allocation infrastructure exists, but TSI
-allowlist enforcement is blocked on a smolvm 0.8.0 upstream bug:
-`smolvm machine create --from <smolmachine> --net --allow-cidr
-X/32` silently drops the allowlist (the persisted
-`agent.config.json` shows `allowed_cidrs: null`, and the running
-VM reaches `127.0.0.0/8` regardless). So while a smolmachines
-bottle is running, host-local dev services (postgres on 5432,
-dev servers, etc.) are reachable from inside the agent even
-though the launcher's `--allow-cidr` says otherwise. The docker
-backend keeps the bottle on a `--internal` docker network and
-doesn't have this issue. Tracked in gitea issue #75; will
-auto-resolve once smolvm honors the flag.
+This enforcement requires a workaround for a smolvm 0.8.0 bug:
+the CLI's `--allow-cidr` flag is silently dropped when combined
+with `--from <smolmachine>`. The launcher patches smolvm's
+persistent state DB
+(`~/Library/Application Support/smolvm/server/smolvm.db`)
+directly between `machine create` and `machine start` to set
+the allowlist. The hack falls away automatically when smolvm
+honors the flag upstream — see the `loopback_alias` module's
+docstring for the investigation trail.
 
 ## Manifest