docs(security): fijar exposición pública en el spec 0001

Decisión del operador: el bus se expone a internet protegido por auth+TLS
(WireGuard pasa a ser una vía más, no la barrera). ufw en om abre 8470/4250;
el server cert lleva SAN con la IP pública 135.125.201.30 + la IP WG 10.42.0.1
+ hostname; los clientes controlados embeben el ca.crt propio (sin Let's Encrypt).
La fase de despliegue 0001f la ejecuta el humano; el agente entrega 0001a-0001e.

dev/issues/0001-bus-auth-and-tls.md

@@ -114,9 +114,17 @@ peer sin material nuevo.
 
 ### TLS (CA self-signed propia)
 
+**Exposición DECIDIDA: pública.** El bus se expone a internet protegido por
+auth+TLS (WireGuard pasa a ser una vía de acceso más, no la barrera). En
+consecuencia: `ufw` en om abre `8470/tcp` y `4250/tcp`, y el server cert incluye en
+su SAN la **IP pública de om `135.125.201.30`**, la **IP WG `10.42.0.1`** (los peers
+internos siguen funcionando) y el hostname de om. Los clientes son todos
+controlados por nosotros (`pkg/client`, binding móvil, gateway web, unibots), así
+que **embeben el `ca.crt`** propio — no hace falta Let's Encrypt ni un dominio
+público apuntando al NATS.
+
 - Generar una **CA propia** una vez (`deploy/tls/ca.{key,crt}`), y un **server
-  cert** para el bus con SAN = IP WG `10.42.0.1`, hostname de om, y (si se decide
-  exponer público) la IP/hostname público.
+  cert** para el bus con SAN = `135.125.201.30`, `10.42.0.1`, hostname de om.
 - `pkg/embeddednats`: `server.Options.TLSConfig` con el server cert. NATS pasa a
   `tls://`.
 - Cliente: `nats.Secure(&tls.Config{RootCAs: caPool})` cargando la CA propia.
@@ -164,11 +172,18 @@ gomobile expone un parámetro nuevo `caPath` en `NewSession`.
 1. Cross-build `CGO_ENABLED=0 GOOS=linux GOARCH=amd64` del `membershipd`.
 2. `scp` binario + `ca.crt` + server cert/key a om (`/opt/unibus/`), dir de datos
    persistente para JetStream/db/blobs.
-3. systemd-system unit, `--bind 10.42.0.1` (o público), `Restart=always`.
-4. Seed del admin (tu identidad) por CLI local en om.
-5. Verificar desde el PC (por WG): handshake TLS, `curl` firmado a `/healthz` OK,
-   `curl` sin firma → 401, conexión NATS de un peer no registrado → rechazada.
-6. unibots local: systemd-user con `caPath` + identidad registrada.
+3. systemd-system unit, `--bind 0.0.0.0` (exposición pública), `Restart=always`.
+4. `ufw allow 8470/tcp` y `ufw allow 4250/tcp` en om.
+5. Seed del admin (tu identidad) por CLI local en om.
+6. Verificar **desde fuera de la VPN** (red pública) y desde la WG: handshake TLS,
+   `curl` firmado a `/healthz` OK, `curl` sin firma → 401, conexión NATS de un peer
+   no registrado → rechazada.
+7. unibots local: systemd-user con `caPath` + identidad registrada.
+
+> **Nota:** la fase de despliegue (0001f: abrir firewall público, scp a om, systemd
+> en el VPS) la ejecuta el humano en coordinación, no el agente autónomo — es una
+> acción outward sobre infraestructura pública. El agente entrega 0001a–0001e
+> (código + tests + CA/cert generados) en master de unibus, listos para desplegar.
 
 # Tests (DoD: golden + edge + error path, evidencia ejecutable)