docs(node): name the exact Ansible command that applies the pin, not 'run the play'

Node configuration in this project is Ansible's — declared in the inventory, reviewed,
version-controlled — and for prod it is the ONLY surface: infra/PROD-PROVISIONING.md
records prod as 3x bare metal with the dev OpenTofu -> Proxmox -> cloud-init path
explicitly not applying, so there is no tofu/cloud-init half to keep in parity for an
/etc/hosts pin.

The pin was already in the right place; what the docs lacked was the command. All four
places now carry the scoped, idempotent one:

    cd infra/ansible && ansible-playbook playbooks/node-baseline.yml \
      -e k3s_hosts=k3s_prod --tags hosts

--tags hosts runs ONLY the /etc/hosts task, so applying this pin cannot drift any other
baseline setting.

Also verified the mechanism is not inert, which is the failure mode this repo keeps
meeting: roles/node_baseline/tasks/main.yml renders node_baseline_hosts_pins into a marked
blockinfile with backup: true, and state: absent when the list empties — so a removed
entry really does leave the node.

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

decisions/2026-10-06-pm-agent-node-resolves-gitea-to-wan.md

@@ -13,9 +13,21 @@ has.
 
 `infra/ansible/inventory/group_vars/k3s_prod/vars.yml` now pins
 `gitea.{{ k3s_base_domain }}` → `192.168.2.20` in `node_baseline_hosts_pins`, beside the
-Keycloak issuer pin that is there for the identical reason. **An operator must run the
-`node_baseline` play for it to reach the nodes** — writing `/etc/hosts` on a node is not
-something Flux or an agent can do.
+Keycloak issuer pin that is there for the identical reason.
+
+**It reaches the nodes the way every other node setting in this project does — through
+Ansible, from the inventory.** Node configuration is Ansible's (and, for the dev VMs,
+OpenTofu's); nothing here touches a node by hand. For prod specifically, Ansible is the
+*only* surface: `infra/PROD-PROVISIONING.md` records that prod is 3× bare metal and that the
+dev path (OpenTofu → Proxmox VM → cloud-init) does not apply, so there is no
+cloud-init/tofu half to keep in parity for this. The one scoped, idempotent command:
+
+    cd infra/ansible && ansible-playbook playbooks/node-baseline.yml \
+      -e k3s_hosts=k3s_prod --tags hosts
+
+`--tags hosts` runs ONLY the `/etc/hosts` task, so applying this pin cannot drift any other
+baseline setting. Running the play is an operator action (it has become/root on prod), but
+the configuration itself is declared, reviewed and version-controlled — not typed on a node.
 
 The docs that described this as an undiagnosed blocker now describe the cause and the fix:
 `platform/pm-agent/README.md`, `runbooks/pm-agent.md` (its symptom row now names the pin and
@@ -86,7 +98,10 @@ with `gitea-settings` the only stage that did not run.
 ## What I did NOT verify
 
 - **That the pin fixes the pull.** It is IaC, and nothing has applied it: `/etc/hosts` on the
-  nodes is written by the `node_baseline` play, which is an operator action. Until that runs
+  nodes is written by the `node_baseline` play's `hosts`-tagged task, which is an operator
+  action. I did confirm the mechanism is not inert — `roles/node_baseline/tasks/main.yml`
+  renders `node_baseline_hosts_pins` into a marked `blockinfile` with `backup: true`, and
+  `state: absent` when the list empties, so a removed entry really leaves the node. Until that runs
   and an image exists, "the node now reaches the Gateway" is a design claim. The evidence
   that it *will* is the Keycloak pin working for the same cause — which I also did not
   re-measure.