podman: document internet exposure and what identity does not gate

lab1 is now published with proxyAllowedZones: [internet]. Enabling OAuth does
not disable Portainer's internal login — POST /api/auth stays live and still
accepts the break-glass admin, confirmed against the public endpoint (422
Invalid credentials, not a refused path). So publishing the console publishes a
password path too; the remedy, if that is unacceptable, is to promote an OIDC
user to administrator and delete the local admin, at the cost of break-glass.

Also records that the operator's admin-VPN overlay (admin, 10.255.1.0/24) is
not in the internal default allow-set, which is why a remote admin on the
WireGuard tunnel also gets 403.

src/containers/podman/INSTALL.md

@@ -85,6 +85,19 @@ are worth knowing when debugging:
   `copy-update-json.sh` documenting that `install-module.sh` computes it, so consumers must
   derive it — from the module's **own** environment, never the default one.
 
+## Publishing the gateway publicly
+
+The module ships internal-only. To expose it (lab1 does this):
+
+```bash
+jq '(.config."network:proxy".proxyAllowedZones) = ["internet"]' \
+    ~/config/podman-<env>.json > /tmp/p.json && mv /tmp/p.json ~/config/podman-<env>.json
+~/TAPPaaS/src/foundation/network/services/proxy/update-service.sh podman-<env>
+```
+
+Read the warning in [README.md](./README.md#publishing-to-the-internet) first: the local admin
+login stays reachable over `/api/auth` once the network restriction is gone.
+
 ## Verify
 
 ```bash

src/containers/podman/README.md

@@ -70,9 +70,26 @@ the intent; if you need per-person isolation, CE will not give it to you.
 ## Placement
 
 No `zone0` is set, so the VM lands in the environment's zone (ADR-007 P5).
-`proxyAllowedZones` is deliberately unset, which gives the internal default — every Active
+`proxyAllowedZones` unset gives the internal default — every Active service zone plus `home`,
-service zone plus `home`, `work`, `mgmt` and the netbird overlay, but **not** the internet — so
+`work`, `mgmt` and the netbird overlay, but **not** the internet. Note the operator's admin-VPN
-members reach the console from a client zone while Authentik decides who gets in.
+overlay (`admin`, `10.255.1.0/24`) is *not* in that default, so a remote admin on the WireGuard
+tunnel gets `403` too. Set `proxyAllowedZones: ["internet"]` to publish it — but read the
+warning below first.
+
+## Publishing to the internet
+
+`proxyAllowedZones: ["internet"]` removes the network restriction, leaving Authentik as the
+gate. That is *almost* true, and the gap matters:
+
+**Enabling OAuth does not disable Portainer's internal login.** `POST /api/auth` stays live and
+still accepts the break-glass admin, whatever the UI shows — verified against the public
+endpoint, which answers `422 Invalid credentials` rather than refusing the path. So publishing
+the console also publishes a username/password path for the local `admin`.
+
+The password is 32 random base64 characters, so guessing it is not the threat; an
+authentication bypass in Portainer itself would be. If you want "gated by identity" to be
+literally true, promote an OIDC user to administrator and then delete the local admin —
+accepting that an Authentik outage then locks everyone out until the volume is restored.
 
 ## Sizing