Stage the KeyCape public-origin headers on Authelia 4.38.

Assistant: grok
Assistant-Session: 01a0e27d-3c2d-7571-a4f8-95442f282b6f

sso-mfa/k8s/keycape/deployment.yaml

@@ -51,8 +51,10 @@ spec:
       containers:
         - name: keycape
           # Image published to the self-hosted Forgejo OCI registry (KEY-WP-0002).
-          # KEY-WP-0012: canonical OIDC subject resolution for /userinfo.
-          image: forgejo.coulomb.social/coulomb/key-cape@sha256:82f1e5ac481e4f963dbd4b05256aee75412c9e9b465d31c9356f5d17f26a6897
+          # NK-WP-0041-T02 path B, key-cape@3b0446e: the in-cluster token call
+          # sends the public HTTPS origin. Staged while Authelia stays 4.38.
+          # Rollback: sha256:82f1e5ac481e4f963dbd4b05256aee75412c9e9b465d31c9356f5d17f26a6897
+          image: forgejo.coulomb.social/coulomb/key-cape@sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3
           imagePullPolicy: IfNotPresent
 
           ports:

workplans/NK-WP-0041-onboarding-journey-usability.md

@@ -215,3 +215,12 @@ allowed back-channel. key-cape is asked whether it will send
 that existing call (path B). Authelia 4.39 trusting those headers from a
 pod, rather than from Traefik, is still unverified. No live config or image
 was changed.
+
+2026-09-27, path B shipped by key-cape and staged on Authelia 4.38.
+`ADMINISTER @ realm:kubernetes/railiance01`, `activation=APPROVED` for this
+image change only. Commit `3b0446e`, tag `main-3b0446e`, digest
+`sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3`.
+The token call stays in-cluster and now sets those two headers from
+`browserBaseURL`. Authelia remains `sha256:46021dc2…` (4.38). Rollback
+digest `sha256:82f1e5ac…`. The 4.39.28 upgrade waits for one attended
+sign-in through the Vergabe demo-company welcome on this image.