Audit servarr-api/servarr-crds public surface to reduce cross-crate coupling

[phaedrus1992]

Summary

Found while landing #560 (cargo-hawk in pre-push/CI). cargo hawk treats servarr_api and
servarr_crds as external-boundary crates via --exclude-crate (see hawk.toml), because
their public API is intentionally consumed by sibling workspace crates
(servarr-resources, servarr-operator) — without the exclusion, hawk flags most of their
surface as "unnecessary public" simply because every consumer happens to live in the same
workspace, which is a false positive for a genuine library boundary.

That exclusion is correct for hawk's purposes, but it also means hawk's dead/unnecessary-public
check no longer covers those two crates at all — including the four-crate split itself. Worth a
manual pass to ask: does every pub item in servarr-api/servarr-crds still have a real
cross-crate consumer, or has some of it gone stale after refactors (e.g. #233, the controller.rs
breakup) the way #536-#543's Transmission self-heal split touched deployment.rs /
controller.rs? A trimmer boundary reduces the coupling surface between the four crates and
gives hawk's excluded-crate list less to blanket-exempt.

Scope

• For each pub item in servarr-api and servarr-crds, confirm it has at least one reachable
  use from a different workspace crate (grep/graph, not hawk — hawk's exclusion means it won't
  do this for us).
• Anything with zero cross-crate consumers: either it's genuinely dead (delete) or it's consumed
  only within its own crate (narrow to pub(crate)/private, same fix as #).
• Anything with exactly one cross-crate consumer: consider whether the abstraction earns its
  keep as a public boundary API vs. being inlined/private with the logic moved to the consumer.
• No urgency — this is architecture hygiene, not a bug. Reasonable to fold into whatever issue
  next touches the servarr-api/servarr-crds boundary rather than a dedicated pass, if that's
  more efficient.