CRD drift: gate rendered output against the committed crd.yaml (keep's spec.backup was silently pruned in-cluster) #5

Capability Alignment

Kubernetes-native deployment: an operator's committed CRD must be the exact
projection of its Rust spec type. When it is not, the API server silently
prunes the missing fields and the operator behaves as if the user never set
them — a class of failure with no error message anywhere in the stack.

Scope

Every app whose CLI ships k8s crd render (tape, relay, keep, defer, lumen,
beam as they gain one) gets a test that renders the CRD from the Rust source
and asserts byte equality with the committed k8s/operator/crd.yaml, failing
with the exact regeneration command in its message.

Explicitly in scope:

• The shared test helper, so each app adds a one-liner rather than its own
  bespoke comparison.
• An audit pass over every existing committed CRD to find the drift already
  present (keep's is proven below; the others are unaudited).
• keep's spec.backup in particular: confirm the backup CronJob renders
  in-cluster once the CRD carries the field.

Explicitly out of scope: Dockerfile render drift (faberline/workspace#2 owns that), and any
change to what the CRDs contain beyond closing measured drift.

Acceptance Criteria

1. cargo test -p <app> fails when crd.yaml is stale, for every app with a
   k8s crd render command.
2. The failure message names the exact command that regenerates the file.
3. Every committed CRD in the repo is byte-identical to its generator output
   at the close of this work item.
4. A Keep CR with spec.backup set survives a real apply and produces the
   backup CronJob — proving the pruning consequence is actually closed, not
   just the file diff.

Reference Context

Found while regenerating keep's CRD for faberline/core#14 (commit fba67420a4).

git show HEAD~1:apps/keep/k8s/operator/crd.yaml | grep -c backup returned
0, while KeepSpec.backup has existed in Rust since 4e22bde50d (faberline/axiom#1249).
v1 CRDs prune unknown fields by default, so spec.backup: on a Keep CR was
being dropped by the API server and the backup CronJob never rendered. The
field was present in Rust, absent from the cluster's schema, and nothing in
CI compared the two.

keep's tests do call crd_yaml() — they assert on its content in isolation,
which is exactly the shape of test that passes while the committed artifact
rots. The regeneration in fba67420a4 also swept in description changes for
replicasPerShard and resources, so the drift was not limited to one
field.

relay's CRD, by contrast, was current — a clean 5-line addition. So this is
per-app rot, not a systemic generator problem, which is precisely why a gate
is the fix rather than a one-time cleanup.