feat: support time_zone for user registration context

authsession/README.md

@@ -138,10 +138,14 @@ The effective DTO contract is:
 | Operation | Request | Success response |
 | --- | --- | --- |
 | `POST /api/v1/public/auth/send-email-code` | `{ "email": string }` | `{ "challenge_id": string }` |
-| `POST /api/v1/public/auth/confirm-email-code` | `{ "challenge_id": string, "code": string, "client_public_key": string }` | `{ "device_session_id": string }` |
+| `POST /api/v1/public/auth/confirm-email-code` | `{ "challenge_id": string, "code": string, "client_public_key": string, "time_zone": string }` | `{ "device_session_id": string }` |
 
 `client_public_key` is the standard base64-encoded raw 32-byte Ed25519 public
 key registered for the created device session.
+`time_zone` is the client-selected IANA time zone name. During the current
+rollout phase, successful confirms forward create-only user registration
+context to `User Service` as `preferred_language="en"` and the supplied
+`time_zone` until gateway geoip-based language derivation is deployed.
 
 Public boundary rules:
 
@@ -151,6 +155,8 @@ Public boundary rules:
   `400 invalid_request`
 - surrounding ASCII and Unicode whitespace is trimmed from input string fields
   before validation
+- `confirm-email-code` requires a non-empty `time_zone` and validates it as an
+  IANA time zone name
 - `send-email-code` remains success-shaped for existing, new, blocked, and
   throttled e-mail paths
 - `confirm-email-code` returns a ready `device_session_id` synchronously on