feat(workstation): prod dnsmasq profile — and CORRECT the topology I had wrong

OPERATOR CORRECTION (2026-09-05). I had been calling the resolver that shadows
prod "a pfSense override" throughout this repo. Both halves of that were wrong:

  - It is the WORKSTATION'S OWN dnsmasq, not pfSense. The live resolver is the
    one NetworkManager spawns (dns=dnsmasq, --conf-dir=/etc/NetworkManager/
    dnsmasq.d); the standalone dnsmasq.service is INACTIVE, so /etc/dnsmasq.d is
    dormant. The dev profile's `address=/.home.keithjackson.dev/192.168.2.50`
    matches the domain AND EVERY SUBDOMAIN, so it also swallowed the whole new
    prod.home.* tree and answered it with dev's address.
  - The k3s prod cluster is NOT behind pfSense. It sits on the SOHO router
    network 192.168.2.0/24, which is pfSense's WAN; pfSense CONTAINS the dev LAN
    192.168.1.0/24. This workstation is on 192.168.2.0/24 too, which is why the
    rules below use prod's real VIPs and need no NAT hop, unlike dev's .50.

New infra/workstation/dnsmasq/ — authored, not click-ops:
  20-prod.home.keithjackson.dev.conf   prod.home.* -> 192.168.2.20 (Gateway),
                                       unifi -> .21, crafty-mc -> .22 (L4 VIPs)
  install.sh                           installs + reloads; refuses non-root

dnsmasq resolves `address=` by LONGEST MATCH, so the prod rules win WITHOUT
editing or reordering the dev profile. PROVEN, not assumed: ran a throwaway
dnsmasq on 127.0.0.1:5354 loaded with both profiles —
  prod.home / gitea.prod / keycloak.prod -> 192.168.2.20
  unifi.prod -> 192.168.2.21   crafty-mc.prod -> 192.168.2.22
  gitea.home / home.keithjackson.dev     -> 192.168.2.50  (DEV, UNCHANGED)
`dnsmasq --test` on the new file: syntax OK.

install.sh pins the destination because getting it wrong is SILENT: a file in
/etc/dnsmasq.d exists, looks installed, and changes nothing. It also uses
`systemctl reload NetworkManager` rather than SIGHUP — dnsmasq does not re-read
its config on SIGHUP, so a HUP would look like it worked and not apply anything.

WHY THE MISLABEL MATTERED: the trap PARTIALLY works. Dev serves a
*.home.keithjackson.dev wildcard cert, which matches prod.home.keithjackson.dev
(one label) so the prod apex returns 200 over VALID TLS, while
keycloak.prod.home.keithjackson.dev (two labels) fails with a certificate-name
error. It reads as a broken prod cert; it is the wrong server answering. I made
exactly that misreading during verification.

Also recorded, because it changes what the apex flip IS: the SOHO router NATs
inbound 443 to the pfSense WAN (192.168.2.102) to serve the EXISTING NON-K3S
production environment, which must stay live until the switch is deliberately
made. So §10a sequence P is not just a k3s-side DNS/TLS change — it is the
legacy-prod cutover, and P as written does NOT cover repointing that NAT. The
two must be planned together or the apex resolves to k3s while inbound 443 still
lands on the legacy box. Phase C touches none of it: prod's Gateway is
192.168.2.20:443 (a different address) and its cert is DNS-01, needing no
inbound 443. And the MinIO timeout is now correctly described as expected
topology — crossing INTO pfSense from its WAN — not a misconfiguration.

VERIFIED: full CI gate PASS (spec-immutability, lint, l0, render-golden, l1).

Refs R-DNS-02, R-ENV-02.

Co-Authored-By: Claude Opus 5 <[email protected]>

clusters/prod/kustomization.yaml

@@ -239,7 +239,7 @@ patches:
       # tiers are SUSPENDED for exactly this reason. The gate is not "review is done", it is:
       #   (a) dev is reconciling on *.dev.home.keithjackson.dev with a Ready wildcard cert, AND
       #   (b) dev's old apex A/CNAME records and their TXT registry entries are GONE from Cloudflare
-      #       (verified against Cloudflare directly — a pfSense override is NOT evidence about public
+      #       (verified against Cloudflare directly — the workstation's dnsmasq is NOT evidence about public
       #       DNS; that mistake was made on 2026-09-04), AND
       #   (c) dev's old `*.home.keithjackson.dev` cert/Certificate is released, because prod ordering
       #       that same name set while dev's still exists counts against LE's duplicate-certificate
@@ -393,7 +393,9 @@ patches:
       # *** NOT YET REACHABLE — velero and the CNPG backups CANNOT be enabled on prod today. ***
       # Measured 2026-09-05 from a throwaway pod INSIDE the prod cluster (not from the workstation,
       # which proves nothing about pod egress): `curl http://192.168.1.9:9000/minio/health/live`
-      # → connection timed out after 15s. pfSense does not route prod's pod network to the dev LAN's
+      # → connection timed out after 15s. EXPECTED TOPOLOGY: prod is NOT behind pfSense — it is on the
+      # SOHO network 192.168.2.0/24, which is pfSense's WAN, while MinIO sits inside pfSense's LAN
+      # 192.168.1.0/24. Reaching it means crossing INTO pfSense from its WAN, which needs a rule
       # MinIO. Until that routing exists, Velero and CNPG would install cleanly and fail every
       # backup at RUNTIME — a tier that reports healthy while no backup exists.
       # Re-test with: bootstrap/standup.sh ... --s3-endpoint http://192.168.1.9:9000 s3check