NET-WP-0020 T4: prepared transit auto-unseal seal stanza (disabled by default)

Commented seal "transit" stanza in the OpenBao server config plus an
'Auto-Unseal via Transit Seal' doc section covering provisioning, seal
migration, pod-restart proof, and the net-kingdom console evidence flags.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/openbao.md

@@ -182,6 +182,28 @@ escrow owner through an out-of-band channel. The initial root token is either
 revoked after a non-root platform-admin token exists or stored as offline
 break-glass material with the same handling as unseal shares.
 
+## Auto-Unseal via Transit Seal (optional, NET-WP-0020 T4)
+
+`helm/openbao-values.yaml` carries a commented `seal "transit"` stanza inside
+the server config. When an external transit OpenBao (or cloud KMS) is
+available, enabling it lets pods unseal automatically after restart — no
+manual share ceremony per restart. Shamir shares become **recovery keys** and
+keep the same escrow handling as unseal shares.
+
+Steps:
+
+1. Provision the transit backend and unseal key; store the transit token in a
+   Kubernetes secret referenced through `server.extraSecretEnvironmentVars`
+   (`BAO_SEAL_TRANSIT_TOKEN`). The token never enters Git.
+2. Uncomment the seal stanza, upgrade the release, and run the seal migration
+   from the attended ceremony posture:
+   `bao operator unseal -migrate` with threshold shares.
+3. Prove auto-unseal: delete the pod, confirm it returns
+   `initialized=true sealed=false` without shares.
+4. In the net-kingdom bootstrap console, select the `auto-unseal-transit`
+   custody model and set `openbao_transit_seal_configured` and
+   `openbao_auto_unseal_verified` in the non-secret metadata.
+
 ## Initial Configuration After Unseal
 
 File audit is configured declaratively in `helm/openbao-values.yaml` with a