pdbmux: ship as k8s container, drop per-VM systemd/RPM delivery

The estate direction is all-in-kubernetes, so pdbmux (a long-running daemon)
should run as an in-cluster service rather than an RPM-installed systemd unit
on each VM. The RPM is for workstation/VM CLI tools only; a daemon does not
belong there.

- Remove packaging/pdbmux.service and drop pdbmux (binary, systemd unit,
  completions) from the RPM/nfpm spec and build-rpm.sh.
- Keep pdbmux in the Makefile build and the test suite.
- Add Dockerfile.pdbmux building a static CGO_ENABLED=0 binary on distroless
  (mirrors encapi's image style).
- Add .woodpecker/docker.yaml to build+push git.unkin.net/unkin/pdbmux:<tag>
  on v* tags via the docker-buildx plugin (droneci/DRONECI_PASSWORD creds,
  same as encapi), with k8s resources set.
- Update README/AGENTS.md: deployment is k8s, config via PDBMUX_* env.

README.md

@@ -1,10 +1,15 @@
 # node-lookup tools
 
-PuppetDB CLIs and one proxy daemon, shipped together in a single RPM:
+PuppetDB CLIs plus one proxy daemon.
+
+The CLIs ship together in a single RPM for workstations/VMs:
 
 - **`node-lookup`** — query and filter PuppetDB node facts.
 - **`pburl`** — print each host's Puppetboard node-page URL.
 - **`pblastreport`** — print each host's last Puppet report time + Puppetboard URL.
+
+The proxy daemon is deployed to Kubernetes as a container image (not in the RPM):
+
 - **`pdbmux`** — merging HTTP proxy over two PuppetDBs (see below).
 
 See [AGENTS.md](AGENTS.md) for the CLI tools' flags, config, and internals. This
@@ -71,11 +76,12 @@ unknown fields survive untouched.
 
 Precedence (lowest → highest): **defaults < config file < env vars (`PDBMUX_*`) < flags**.
 
-Config file: `$XDG_CONFIG_HOME/pdbmux/config.yaml` (as an RPM/systemd service:
-`/etc/pdbmux/config.yaml`).
+Config file: `$XDG_CONFIG_HOME/pdbmux/config.yaml`. In Kubernetes, configuration
+is supplied entirely via `PDBMUX_*` env vars (no config file), which is the
+supported deployment path — see [Deployment](#deployment).
 
 ```yaml
-# ~/.config/pdbmux/config.yaml  (or /etc/pdbmux/config.yaml under systemd)
+# ~/.config/pdbmux/config.yaml  (local dev; in k8s use PDBMUX_* env instead)
 listen: ":8080"
 backends:
   - name: old
@@ -123,15 +129,30 @@ NODE_LOOKUP_URL=http://localhost:8080/pdb/query/v4/facts pblastreport somehost
 
 ### Deployment
 
-The RPM installs `/usr/bin/pdbmux` plus a systemd unit at
-`/usr/lib/systemd/system/pdbmux.service` (reads `/etc/pdbmux/config.yaml`):
+`pdbmux` runs **in Kubernetes** as a container, in line with the all-in-k8s
+estate direction — it is not shipped as a per-VM RPM/systemd service. The image
+is built and pushed on every `v*` tag (`.woodpecker/docker.yaml`) to:
 
-```bash
-systemctl enable --now pdbmux
-curl -s localhost:8080/healthz
+```
+git.unkin.net/unkin/pdbmux:<tag>
 ```
 
-Suited to run as an RPM-managed daemon on a VM alongside the existing Puppet
-infra during migration; the same static binary is container-ready for a future
-k8s deployment (single listener, `/healthz` liveness/readiness probe, config via
-`PDBMUX_*` env).
+It is a minimal static (`CGO_ENABLED=0`) binary on a distroless base
+(`Dockerfile.pdbmux`), configured entirely via `PDBMUX_*` env vars, with a
+single HTTP listener and `/healthz` for liveness/readiness probes.
+
+The Deployment/Service/Gateway manifests live in the estate's `argocd-apps` repo
+under `apps/base/pdbmux/` (namespace `pdbmux`, 2 replicas), and it is exposed to
+VM/workstation `node-lookup` consumers over HTTPS at:
+
+```
+https://pdbmux.k8s.syd1.au.unkin.net
+```
+
+Locally you can still run the binary directly for development:
+
+```bash
+PDBMUX_BACKENDS='old=http://puppetdbapi.service.consul:8080,new=http://puppetdb.puppet.svc.cluster.local:8080' \
+  pdbmux serve
+curl -s localhost:8080/healthz
+```