fix(observability): bind Alertmanager to loopback (#70)

[Gerrrt]

What changed

Alertmanager (9093) now binds to 127.0.0.1 instead of ${BIND_ADDR}. Prometheus, Loki, Grafana and the Alloy syslog receiver are unchanged. Plus ADR-0012 and the docs that stated the old arrangement.

Why

Closes #70. Anyone who could reach Alertmanager could create a silence, which switches off an alert using the system that would otherwise have recorded the act — the one write surface here whose abuse leaves no trace. Nothing off-host uses port 9093: silences are reached through Grafana, which proxies Alertmanager over the compose network behind a login. So closing it costs no capability.

The scope of this PR shrank, and why

It originally moved Prometheus and Loki to loopback too, on the strength of docs/roadmap.md saying only the monitoring host ran an agent. That document was about a day out of date. Checking the host instead:

$ curl -sG localhost:9090/api/v1/query --data-urlencode 'query=count by (host) (node_uname_info)'
oracle, prometheus

$ curl -s 'localhost:3100/loki/api/v1/label/host/values'
morpheus, oracle, prometheus

oracle has been remote-writing for ~18 hours (720 samples in 12h, 1113 in 24h), 378 distinct metric names, 42 log lines in the last 10 minutes. It is not a Prometheus scrape target — all 13 active targets are compose-internal or SNMP — so 10.0.99.20:9090 and :3100 are its only path. Loopback-binding them would have cut metrics and logs silently, because Alloy retries with backoff and buffers rather than failing loudly.

A second assumption also failed: narrowing BIND_ADDR to the management IP looked like cheap defence in depth, on the reasoning that a 2012 MacBook Pro has Wi-Fi. ip -br addr shows one interface, a USB ethernet adapter already on 10.0.99.20/24. 0.0.0.0 and the management IP are the same thing here, so that would have added a failure mode and bought nothing.

docs/roadmap.md #88 is corrected here — oracle is done, Saruman is what remains.

Blast radius

Monitoring host (prometheus, 10.0.99.20) only. Removes one port from VLAN reachability, adds none.

• Alertmanager's externalURL becomes on-host-only. It seeds a JSON field in webhook payloads; no receiver template renders it, so no notification text changes. Left pointing at MONITORING_HOST because that is still the host you would tunnel to. Off-host, silences are in Grafana under Alerting.
• A browser bookmark to 10.0.99.20:9093 stops working. Nothing in the repo documents one — every runbook already drove Alertmanager from localhost on the host or via docker exec ... amtool, both unaffected.
• 127.0.0.1 is a host boundary, not a user one: any local account or host-network container on the monitoring host still reaches Alertmanager unauthenticated. Stated in the ADR rather than claimed away.
• oracle is untouched, which is the point of the revision.
• No flags changed. Reachability was the problem, not --web.enable-remote-write-receiver, --web.enable-lifecycle or auth_enabled: false.

Left open, deliberately

Prometheus and Loki stay published and unauthenticated. Anything that can route to 10.0.99.20 can read every metric and log line, inject metrics, and delete log ranges. Firewall default-deny is the only control, and ADR-0002 already records what that leaves: "a compromised workstation reaches Winterfell." Recorded as an accepted residual in SECURITY.md beside the SNMP and unencrypted-disk entries, not quietly carried. Closing it properly needs authentication in front of the ingest ports plus a credential on every agent — separate work, and a new secret to rotate.

• No change to network segmentation or firewall rules
• No new port published to a VLAN that could not already reach the service
• No credential added outside secrets/*.sops.yaml

Verification

make validate passes with nothing skipped. scripts/check_docs.py compares the ports table against compose.yaml; confirmed the guard is live rather than vacuously passing by reverting a row and watching it fail.

Resolved binds from docker compose config against a seeded validation env:

alertmanager     127.0.0.1 : 9093 -> 9093/tcp
alloy            127.0.0.1 : 12345 -> 12345/tcp
alloy              0.0.0.0 : 1514 -> 1514/udp
grafana            0.0.0.0 : 3000 -> 3000/tcp
loki               0.0.0.0 : 3100 -> 3100/tcp
prometheus         0.0.0.0 : 9090 -> 9090/tcp

Not yet deployed. After make up on the monitoring host: ss -ltn shows 127.0.0.1:9093, and 9090/3100/3000 still on 0.0.0.0. Then the checks that prove nothing quietly broke — Grafana -> Alerting -> Silences can create one, oracle still appears in count by (host) (node_uname_info) and its log stream is still advancing, {host="morpheus"} still returns firewall logs, Prometheus targets all UP, and make reload succeeds.

• make validate passes
• Deployed to the lab and confirmed working
• Docs updated (docs/, service README, or docs/roadmap.md)