fix(node): pin gitea to the Gateway VIP — containerd was resolving it to the non-hairpinned WAN

The pm-agent image pull failed TLS verification, and the previous entry on this branch
recorded it honestly as not diagnosed. Diagnosed now, and it is not about the image.

containerd pulls as a NODE process, so it resolves through node_baseline_dns_servers (the
LAN gateway, deliberately not PiHole) and gets the public answer: a CNAME to
wan.home.keithjackson.dev -> 136.51.115.252, measured via both 1.1.1.1 and 8.8.8.8. This
router does not hairpin, so WAN:443 answers with its own placeholder certificate —
measured with the right SNI from the workstation:

    subject=C=ZZ, ST=Somewhere, L=Unknown, O=%D342e7e6b, CN=%D
    No extensions in certificate

No extensions means no subjectAltName, which is exactly 'certificate is not valid for any
names'. Meanwhile 192.168.2.20 IS the shared Gateway's VIP and its https listener serves
the real Let's Encrypt *.home.keithjackson.dev. The Gateway, the wildcard cert and the
digest were never implicated — only the node's answer.

This file already documents the identical failure for the Keycloak issuer, measured from
k3s-prod-2/-3 on 2026-10-03 (curl exit 60, ssl_verify_result=18), and already carries the
mechanism that fixes it. gitea is simply the second node process to need it; containerd is
a node process and nobody had added it. An operator must run the node_baseline play.

Also records, where an operator reads them, that the agent authenticates to Gitea with a
local account and a scoped PAT by decision — and why the federated alternative is not
merely unchosen but unavailable: Gitea implements only the Authorization Code Grant and
validates no third-party OIDC token, so a Keycloak service-account token cannot
authenticate to its API or to git-over-HTTP.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/plans/pm-agent-issue-to-pr.md

@@ -236,12 +236,14 @@ about runtime behaviour in this document is a design claim, not a measurement.
 1. **Make the registry pullable, THEN build, push, pin.** Measured after the merge, and
    neither half is declared anywhere in this repository
    (`decisions/2026-10-05-pm-agent-registry-pull-prereq.md`):
-   (i) the cluster's nodes cannot verify the registry's TLS certificate — containerd reports
-   `x509: certificate is not valid for any names` for `gitea.home.keithjackson.dev`, while
-   that name serves a healthy Let's Encrypt wildcard from the LAN; (ii) an unauthenticated
-   client gets nothing from that registry and no `imagePullSecret` exists in the tree, so
-   either one is added or anonymous package reads are allowed. Only then does the digest
-   matter. Operator runs `infra/agent/build-image.sh`, pushes, and one PR replaces both
+   (i) the nodes resolved the registry hostname to the WAN IP and failed TLS against the
+   router's `CN=%D` placeholder certificate — **diagnosed and fixed** by pinning
+   `gitea.{{ k3s_base_domain }}` to the Gateway VIP in `node_baseline_hosts_pins`, the same
+   pin the Keycloak issuer already carries; an operator must run the `node_baseline` play;
+   (ii) the pull is still unauthenticated and no `imagePullSecret` exists in the tree — with
+   the credential decision now being local Gitea accounts with PATs, that means a
+   `dockerconfigjson` for an account whose token carries `read:package`. Only then does the
+   digest matter. Operator runs `infra/agent/build-image.sh`, pushes, and one PR replaces both
    placeholder digests. Expect the build itself to need iteration too: the nodejs module
    stream and the npm install have never run against this base. The same two blockers sit in
    front of `conformance-runner`, which shares the registry path and has never been pulled.