Auto-verify Sign in with Apple emails

Apple OIDC mapper now marks the email verified unconditionally via
verified_addresses. SIWA cryptographically proves control of the Apple ID and
Apple owns/verifies the (relay) email, so a code is redundant. Gating on
Apple's `email_verified` claim was unreliable — Apple omits it on many
authorizations, which made verification random (sometimes a surprise code
prompt). Password sign-ups still verify via the honeyDue API flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

deploy-k3s/manifests/kratos/configmap.yaml

@@ -207,14 +207,26 @@ data:
     // returns the name on the very first authorization and not in the ID
     // token claims, so only email is mapped here.
     //
-    // NOTE: we intentionally do NOT carry Apple's email_verified across via
+    // Sign in with Apple emails are marked verified UNCONDITIONALLY: completing
-    // verified_addresses. Product decision: every account-creation flow —
+    // SIWA cryptographically proves the user controls that Apple ID, and Apple
-    // including Sign in with Apple — must complete an email verification step.
+    // owns/verifies the (relay or real) email, so a 6-digit code would be
+    // redundant. We deliberately do NOT gate this on Apple's `email_verified`
+    // claim — Apple omits that claim on many authorizations (only sends it on
+    // the first grant), which made auto-verification random: sometimes verified,
+    // sometimes a surprise code prompt (observed 2026-06-03). Marking it
+    // verified on every SIWA makes the behaviour consistent: Apple users never
+    // see a code; password sign-ups still verify via the honeyDue API flow.
     local claims = std.extVar('claims');
     {
       identity: {
         traits: {
           email: claims.email,
         },
+        verified_addresses: std.prune([
+          if 'email' in claims then {
+            via: 'email',
+            value: claims.email,
+          },
+        ]),
       },
     }