Per `feedback_no_mvp_no_workarounds.md` target-state rule + matrix assertion drift on TC-124, TC-125, TC-159, TC-160, TC-161, TC-176, TC-190, TC-285 (8 TCs in iter-12 audit Phase 4 cluster A): each Sovereign owns its KC realm named after the tenant short-name, not a hardcoded literal `sovereign`.
bp-keycloak chart 1.4.1 → 1.5.0:
- New value `sovereignRealm.name` (default `sovereign` for backward compat with overlays not yet migrated)
- New value `sovereignRealm.displayName` (default `Sovereign`)
- Realm import JSON `"realm"` field + catalyst-kc-sa-credentials Secret `realm` key both flow from `$realmName` so Keycloak realm name and catalyst-api `CATALYST_KC_REALM` env stay in sync (no auth-mismatch risk)
omantel chroot overlay:
- bp-keycloak HelmRelease pinned to chart 1.5.0
- `sovereignRealm.name: omantel` + `displayName: "Omantel Sovereign"` per matrix tenant convention
bp-catalyst-platform 1.4.120 → 1.4.121: chart bump triggers catalyst-api StatefulSet restart so it picks up the new mirrored Secret with realm=omantel. The cutover step-06 patches HR.spec.chart.spec.version dynamically per `incidents.md`.
Backward compat: charts not setting sovereignRealm.name (otech, _template) keep realm `sovereign` (no behaviour change). The contabo Catalyst-Zero realm `openova` is a separate KC instance untouched by this change.
6d2006ae12