DB apps fail on bare k3s: app-ns NetworkPolicy blocks CNPG initdb→apiserver egress (gate only runs on k3d) #89

Summary

Database-backed apps fail to bootstrap on bare single-VPS k3s platforms: CNPG initdb can't reach the kube-apiserver because the generated app-namespace NetworkPolicies assume the apiserver is in 172.16.0.0/12 (true on the k3d gate rig, false on a real VPS where the apiserver is the node IP on :6443). Every app with a DB hangs at "Setting up primary".

Root-caused and fixed in plat/gitops (generate-allow-egress now allows the apiserver ClusterIP :443 + 0.0.0.0/0:6443), validated live on the product-garden.com granddaughter (crew-built app reached preview 200). This issue tracks the durable lesson + the gate gap.

Why the gate missed it

The coldstart/GATE harness germinates only on k3d (vxrail), where the apiserver container IP falls inside the 172.16/12 allow. The bug is invisible there and only appears on a bare-k3s substrate (HYB path). This is the exact category HYB-2 (#35) exists to catch.

Follow-up

• [ ] Germinate at least one bare-k3s target in CI (or a k3d cluster whose apiserver is outside 172.16/12) so substrate-divergent networking regressions are caught automatically.
• [ ] Consider moving allow-egress-postgres's apiserver intent out of the renderer's hardcoded 172.16/12 and into the same substrate-agnostic rule.

Fix commit: plat/gitops fix/apiserver-egress-bare-k3s.