GridSiteSpec.sovereignty_zone is schema-validated but never read by routing/placement logic (unenforced-CRD-field pattern recurring)

[jordigilh]

Summary

GridSiteSpec.sovereignty_zone (operator/src/crd/grid_site.rs:45) is accepted and
schema-validated as part of the GridSite CRD, with a doc comment claiming it is
"for data residency constraints." A repo-wide search shows it is never read by
any routing, placement, or scoring logic — it only appears in the field definition
itself and as None in test-fixture literals in operator/src/controller/grid_site.rs
(lines 671, 693, 1013, 1225).

By contrast, the sibling fields region (line 42) and zone (line 48) on the same
struct are genuinely read and used: operator/src/resources/geography.rs:117
derives locality tiers from spec.region and spec.zone. sovereignty_zone has no
equivalent consumer anywhere in the codebase.

Evidence

• operator/src/crd/grid_site.rs:44-45:

  /// Sovereignty zone for data residency constraints.
  pub sovereignty_zone: Option<String>,

• Only other occurrences repo-wide (grep -rn sovereignty_zone --include='*.rs'):
  operator/src/controller/grid_site.rs:671,693,1013,1225 — all sovereignty_zone: None,
  inside test fixture struct literals.
• No occurrence in operator/src/resources/routing_overlay.rs,
  operator/src/resources/geography.rs, or any scoring/candidate-ordering code.
• Contrast: operator/src/resources/geography.rs:34,117 — region/zone are
  documented as, and actually used to, derive locality tiers
  (same_site/same_zone/same_region/cross_region).

Risk

An operator who sets spec.sovereignty_zone on a GridSite — reasonably expecting
it to constrain routing for data-residency/compliance purposes, per its own doc
comment — gets silent no-op behavior: the field is accepted by the API server and
never influences which providers or sites the routing overlay considers eligible.
This is the same "accepted but unenforced CRD field" defect class already confirmed
this session on AgentToolProvider.access_policy, now found a second time on a
different CRD — indicating this is a systemic pattern in this codebase rather than
an isolated oversight, and other CRD fields should likely be audited for the same
issue.

Suggested fix

Either (a) wire sovereignty_zone into placement/scoring the same way region/zone
are wired in geography.rs (as a hard eligibility filter, given its residency intent
— not just an ordering signal), or (b) if data residency enforcement is intentionally
out of scope for now, remove the field (or mark it clearly unimplemented in its doc
comment and CRD schema description) so operators don't silently rely on unenforced
behavior.

Severity: Medium