Pin caller-auth digest in warn on independently rollable overlay pins

The sanctioned Helm chart could not promote ADR 0004 at all, and the
emergency manifests selected enforce. That made a FLEX-WP-0011 apply
either a no-op or a global 401. First production pin is now warn, per
consumer, on CI digest sha256:138aa347… . Enforce stays a later
per-consumer flip so USER-WP-0023-T03 can close without waiting on
tenant-engine.

workplans/FLEX-WP-0015-tenancy-posture-conformance.md

@@ -14,7 +14,7 @@ related_workplans:
   - FLEX-WP-0004
   - FLEX-WP-0011
 created: "2026-08-17"
-updated: "2026-08-18"
+updated: "2026-08-19"
 state_hub_workstream_id: "31846b19-c2a3-428e-950b-5985bc9146eb"
 ---
 
@@ -110,38 +110,50 @@ Ship through the FLEX-WP-0011 staged-promotion path, not by direct apply.
 ServiceAccount TokenReview with a separately projected reviewer identity and
 exact `resource.system` → ServiceAccount bindings. Both check endpoints share
 the choke point; missing/mismatched identity fails 401/403 and reviewer outage
-fails 503. Unit and handler tests include the required unbound request. Desired
-manifests select enforce mode and carry narrow TokenReview RBAC. The running
-digest is unchanged, so `tenancy.current.A` honestly remains 0 while
-`tenancy.implemented.A` is 2. Source committed as `1e1e077`.
+fails 503. Unit and handler tests include the required unbound request. Source
+committed as `1e1e077`.
 
-**Remaining, in this order — the sequence is a constraint, not a preference.**
-`ops-warden` ruled on rollout (2026-08-17) and `user-engine` asked for the same:
+2026-08-19 overlay outcome: the sanctioned Helm chart did not render caller
+auth at all, so a FLEX-WP-0011 pin of the new digest would have stayed
+`disabled`. That is now wired. Desired emergency manifests and production
+values select **`warn`**, not `enforce` — applying the previous enforce
+manifests was the hazard. CI image `sha256:138aa3471c46bca6e814691fa1e6520aedda3dffd743e6b09141ab433afdb64b`
+(`main-3de72fe`, built 2026-08-18T13:25Z) contains the TokenReview flags.
+The running cluster digest is still unchanged, so `tenancy.current.A`
+remains 0 while `tenancy.implemented.A` is 2.
 
-1. Build and pin a new immutable digest carrying the caller-auth code.
-2. Promote it in **`warn` mode**, not `enforce`. The reviewed desired manifests
-   in `deploy/` select `enforce` because that is the end state — applying them
-   directly is the hazard. Warn authenticates and logs failures without
-   rejecting, so it is safe for an unmigrated caller.
-3. Confirm the warn logs are clean of unauthenticated callers. `user-engine` is
-   migrated and deployed as of 2026-08-18 (image `sha256:c501aeb2…`, token at
-   `/var/run/secrets/flex-auth-caller/token`). `tenant-engine`'s caller status
-   is **unconfirmed — asked 2026-08-18**; promoting `enforce` while their
-   client sends no token 401s every check and blocks their write paths.
-   `ops-warden` adopts the calling side on its own schedule.
-4. Flip to `enforce`, then capture the live negative probe. `user-engine` has
-   the three assertions written and ready in their
-   `docs/flex-auth-caller-identity.md`; they deliberately have not run it,
-   because against an unenforced digest "no token returns 401" comes back as a
-   normal decision and would record as false evidence.
-5. Only then may `policy.enabled` flip anywhere — `ops-warden` names that the
-   real deadline, and it is the same gate as FLEX-WP-0007.
+**Better path than a global enforce flip.** The two production Deployments
+are independently rollable (FLEX-WP-0011). USER-WP-0023-T03 only probes
+`flex-auth-user-engine`. Serializing that probe on tenant-engine's caller
+status would 401 tenant-engine writes if we enforced them together, and
+would delay user-engine A2 evidence for no safety gain. Sequence:
 
-**Operator gate.** Steps 1–4 need cluster credentials this session does not
+1. Pin the caller-auth digest in overlay + emergency manifests — **done
+   2026-08-19**, first mode `warn` on both consumers.
+2. Operator: promote each pin in warn via `helm upgrade --install
+   flex-auth-<consumer> charts/flex-auth --namespace flex-auth -f
+   values/<consumer>.yaml`. Isolated canary may boot the same digest with
+   caller-auth disabled. Do not `kubectl apply` an enforce manifest.
+3. Confirm warn logs per consumer. `user-engine` is migrated and deployed
+   as of 2026-08-18 (image `sha256:c501aeb2…`, token at
+   `/var/run/secrets/flex-auth-caller/token`). `tenant-engine` source and
+   desired manifests already project that token and send it; live digest
+   is still unconfirmed. Warn is safe either way. `ops-warden` adopts the
+   calling side on its own schedule.
+4. Flip **user-engine only** to `enforce` (`callerAuth.mode: enforce` in
+   `values/user-engine.yaml`, same digest). Then capture the live negative
+   probe from a user-engine pod. The three assertions are already written
+   in user-engine `docs/flex-auth-caller-identity.md`; they must not run
+   against warn, because "no token returns 401" would still be a decision.
+5. Flip tenant-engine to enforce only after its warn logs are clean.
+6. Only then may `policy.enabled` flip anywhere — `ops-warden` names that
+   the real deadline, and it is the same gate as FLEX-WP-0007.
+
+**Operator gate.** Steps 2–5 need cluster credentials this session does not
 have: `kubectl` returns `Unauthorized` and the context is `default`, which
 `tenant-engine` documented on 2026-08-16 as indistinguishable from a
-wrong-cluster KUBECONFIG. Promotion follows FLEX-WP-0011 staged promotion and
-the CI image build, not a hand-built image.
+wrong-cluster KUBECONFIG. Promotion follows FLEX-WP-0011 and the CI image,
+not a hand-built image.
 
 `RISK-F-0001` (risk-nexus) tracks this A0 externally. Their NetworkPolicy
 question was answered 2026-08-18: both Deployments carry an ingress policy
@@ -218,6 +230,7 @@ correct-looking responses, exactly like the two silent pin rollbacks the
 estate has already been bitten by.
 
 Completed 2026-08-18. `make verify-posture` checks the current/implemented
-distinction, both authenticated handlers, enforce-mode desired manifests,
-TokenReview RBAC, absence of a latent tenant-engine caller, and the stateless
-deployment assumptions behind `R: n/a`.
+distinction, both authenticated handlers, warn-or-enforce desired manifests
+and overlay pins, TokenReview RBAC, absence of a latent tenant-engine caller,
+and the stateless deployment assumptions behind `R: n/a`. First production
+pin is warn; enforce is the end state, flipped per consumer.