feat(metrics): pre-seed known channels at zero on startup

[rubenhensen]

Summary

• Pre-seeds the six known channels (website, staging-website, outlook, thunderbird, api, unknown) to 0 for both cryptify_uploads_total and cryptify_upload_bytes_total in Metrics::new().
• Renames the corresponding test from render_emits_zero_counters_when_empty to render_preseeds_known_channels_at_zero and iterates over KNOWN_CHANNELS so the contract stays self-validating if the list grows.

Why

Without pre-seeding, Prometheus only registers a series for {channel="X"} the first time an upload from that channel finalizes. The very first sample is value 1, and PromQL increase(...[1h]) over a window where the series has only post-event samples returns nothing — dashboards then read 0 for a channel that actually saw traffic until ~an hour after the first upload. The effect compounds on every cryptify pod restart (each rollout blanks the in-memory counters).

With this change all six channels emit a 0 line on the first scrape, so:

• increase(...) has a 0-valued baseline to differentiate against.
• Per-channel dashboard panels show every channel from the start, not just the ones that happen to have had traffic since the last rollout.
• The if uploads.is_empty() fallback in render() becomes effectively dead, but is left in place defensively.

Test plan

• cargo test metrics — 13/13 pass, including the rewritten preseed test that iterates over KNOWN_CHANNELS.
• After deploy: scrape /metrics and confirm all six channel= rows are present at 0 before any uploads have happened.
• In Cockpit Grafana Explore: cryptify_uploads_total returns six rows (one per channel) immediately on the first scrape post-rollout.

[rubenhensen]

/dobby review

[dobby-coder]

Looks good. Pre-seeding the six known channels at 0 in Metrics::new() is the right fix for the PromQL increase() baseline problem you described — the first scrape after a pod restart now exposes the full label set, so per-channel dashboard panels stay populated from t=0 instead of appearing only after the first matching upload.

Verified locally:

• cargo test metrics — 13/13 pass, including the rewritten render_preseeds_known_channels_at_zero which iterates over KNOWN_CHANNELS so the contract grows with the list.
• The seeded entries flow through render() via the existing BTreeMap iteration; sort order is stable (api, outlook, staging-website, thunderbird, unknown, website), which matches what Prometheus expects.
• record_upload's entry().or_insert(0) += 1 pattern composes correctly with the seeded zeros — pre-seeded channels increment from 0, novel channels still appear lazily.

Minor non-blocking observations (don't gate the merge):

• Metrics::default() (auto-derived) still exists and now diverges from Metrics::new() in that it does not pre-seed. Every call site in the tree uses ::new(), so this is fine today, but a future contributor could trip on it. A short doc comment on Metrics::new() calling out "prefer this over default()" — or removing the #[derive(Default)] if it isn't needed elsewhere — would close the trap. Defer if you prefer.
• As the PR description notes, the if uploads.is_empty() fallback in render() is now effectively unreachable. Leaving it as a belt-and-suspenders guard is reasonable; just flagging that it's drifted from being load-bearing.

Nothing in the rules or repo notes conflicts with this change. Ship it.