feat: support time_zone for user registration context

ARCHITECTURE.md

@@ -68,7 +68,7 @@ The gateway already distinguishes:
 The public auth contract is:
 
 * `send-email-code(email) -> challenge_id`
-* `confirm-email-code(challenge_id, code, client_public_key) -> device_session_id`
+* `confirm-email-code(challenge_id, code, client_public_key, time_zone) -> device_session_id`
 
 The authenticated request contract is based on:
 
@@ -217,6 +217,11 @@ Important architectural rules:
 * active-session limits are configuration-driven;
 * `send-email-code` stays success-shaped for existing, new, blocked, and throttled email flows.
 
+When `confirm-email-code` reaches first successful completion for an e-mail
+address that does not yet belong to a user, auth may pass create-only
+registration context to `User Service` during the synchronous ensure/create
+step.
+
 Direct integrations:
 
 * synchronous to `User Service` for user resolution/create/block decision;
@@ -619,10 +624,10 @@ sequenceDiagram
     Auth-->>Gateway: challenge_id
     Gateway-->>Client: challenge_id
 
-    Client->>Gateway: POST confirm-email-code
-    Gateway->>Auth: confirm-email-code
-    Auth->>Auth: validate challenge/code/public key
-    Auth->>User: resolve/create/block
+    Client->>Gateway: POST confirm-email-code(time_zone)
+    Gateway->>Auth: confirm-email-code(time_zone)
+    Auth->>Auth: validate challenge/code/public key/time_zone
+    Auth->>User: resolve/create/block with create-only registration context when needed
     User-->>Auth: user_id or deny
     Auth->>Auth: create device_session
     Auth->>Redis: write gateway session projection