fix(pm-agent): the agent is IN the cluster — one git host, the cluster-local service name

An in-cluster consumer reaches a service by its *.svc.cluster.local name, which is by
design a different path from how a client outside the cluster reaches the same service.
pm-worker's host allowlist accepted TWO values: the cluster-local name and the external
hostname gitea.home.keithjackson.dev. The second is removed.

It was never needed — nothing sets it — it would route in-cluster traffic out through the
Gateway and back for no reason, and as an ACCEPTED value it widened the allowlist to a
host reachable over the namespace's world:443 egress rule, which is precisely the
injection shape the allowlist exists to refuse.

probe-validation.sh now pins that: 20 refusals, including the external hostname, the
cluster-local name over https, and the cluster-local name on the wrong port.

Also corrects a remark in the handoff entry: I cited cluster-vars' GATEWAY_VIP
(192.168.1.53) as suspicious next to the nodes' 192.168.2.x. That was noise — those base
cluster-vars values are dev-era leftovers for a decommissioned cluster and say nothing
about prod. None of the measured facts depended on it.

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

decisions/2026-10-05-pm-agent-registry-pull-prereq.md

@@ -97,10 +97,14 @@ Read-only, through the pinned toolbox, against the live prod cluster.
   does not. I did not diagnose it: I did not read the nodes' resolver or
   `/etc/rancher/k3s/registries.yaml` (node files, not reachable read-only through the API),
   and I did not check whether the node resolves the name to the same `192.168.2.20` the
-  workstation does or to something else. Note `cluster-vars` has
-  `GATEWAY_VIP: 192.168.1.53` while the nodes are `192.168.2.10-12` and the name resolves
-  to `192.168.2.20` — three different subnets in one sentence is a reason to measure rather
-  than to theorise, and I have not.
+  workstation does or to something else.
+
+  **A correction to a remark I first wrote here:** I cited
+  `cluster-vars`'s `GATEWAY_VIP: 192.168.1.53` as suspicious next to the nodes'
+  `192.168.2.x`. That was noise — the operator confirms those base `cluster-vars` values are
+  **dev-era leftovers for a cluster that is decommissioned**, so the 192.168.1.x addresses in
+  that file say nothing about prod and should not be read as evidence about anything. The
+  measured facts stand on their own and none of them depended on that knob.
 - **Whether the package would be pullable once authenticated.** Nothing has ever been
   pushed to that path, so "a credential is sufficient" is untested. The only thing
   established is that no credential is insufficient.