chore(secrets): point Alertmanager at a real receiver

[Gerrrt]

Makes alerting work at all. It never has.

What changed

ALERTMANAGER_WEBHOOK_URL only. One key, values encrypted.

Why

The webhook was still the placeholder from observability.example.yaml:
ntfy.example.invalid. Alertmanager resolved it on every notification, failed
DNS, and gave up after 15 retries:

err="urgent/webhook[0]: notify retry canceled after 15 attempts:
     dial tcp: lookup ntfy.example.invalid on 127.0.0.11:53: no such host"

No alert has ever been delivered since the stack was built. All 40 rules
were firing into nothing. AlertmanagerNotificationsFailing — the rule whose
whole job is to catch this — was undeliverable for the same reason it was
firing.

Why an external receiver

Deliberate. The alerting stack runs on the rack it monitors, so a self-hosted
receiver dies with the thing it is meant to warn about. That includes a mains
loss, which is precisely the scenario the missing UPS battery makes
unrecoverable — see #30.

The topic is a 20-character random string from scripts/gen-secret.sh and
functions as a bearer secret, which is why it belongs in SOPS rather than a
config file.

Trade-off, stated plainly: alert text — hostnames, addresses, roles —
transits a third-party server. That is information SECURITY.md deliberately
keeps out of this repository. Moving to a self-hosted or private receiver is one
make secrets-edit away and needs no other change.

Blast radius

Secrets file only. No rule, route, receiver definition, service or segmentation
change. The running stack already holds this value.

• 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 render && make reload, then polled the topic. Both alerts stuck in the
retry queue were delivered:

message 1  receiver=default  IloBatteryCondition        shiva 10.0.30.10
message 2  receiver=urgent   AlertmanagerNotificationsFailing
total messages delivered: 2

No notify errors in the Alertmanager log since the reload.

• make validate passes
• Deployed to the lab and confirmed working
• Docs updated — n/a

Follow-up worth knowing

Alertmanager posts raw JSON to a generic webhook, so ntfy renders each alert as
a wall of JSON rather than a readable notification. Functional, not pleasant.
Worth a formatting bridge or ntfy-specific receiver later.