i18n: sys_user.locale stores a mis-cased tag (zh-cn, ZH-CN) with 200, and the console then renders that user's session in English — #29833 corrected case for translation locales only #29895

domain:devx#1 · os-warren · session_01JQwxbZtZMhQkARKJtViA9U

Filing gate: ① a product defect, observed beside the clauses (i18n.notification-localized-and-clears), reach: the public data door PATCH /api/v1/data/sys_user/:id, measured live.
Business reason: a user's language preference written by an import, an identity-provider sync or an admin script as zh-cn is accepted and stored, and that user then gets an English console with no error anywhere — the same silent failure #28993 described for translation files, on the user-preference door. #29833 folded translation locales to BCP-47 case; the user record still stores what it is given, while the server's i18n routes fold case and the console matches exactly, so two surfaces disagree about one user's language.
Reader who acts: the triage seat, then a domain:server implementer on the sys_user.locale write (fold with the same canonical-case helper #29833 added, or refuse an unsupported tag), with the console's exact-match pick as the alternative landing site. QA suggestion only: p2.
Duplicate search (incl. closed): sys_user locale case zh-cn → 66 hits, locale zh-cn console English user → 143 hits. Nearest: #28993 (closed by #29833, translation locales only), #28107 (open, French not a platform locale — a different gap), #29428 (open, platform locale table). None covers case on the user record.

Reproduction (subject 589049b0, stock showcase boot)

1. As a member, PATCH /api/v1/data/sys_user/OWN_ID {"locale":"zh-cn"} → 200; the row reads locale: "zh-cn" (ZH-CN likewise).
2. Reload /_console/apps/com.example.showcase/showcase_task: html lang is en-US, headers read Title / Project / Assignee, "Open inbox".
3. Control: {"locale":"zh-CN"} → the same page renders lang zh-CN, 标题 / 项目 / 负责人.

Expected: the door stores zh-CN (as #29833 does for translations) or the console resolves case-insensitively, as the i18n routes and Accept-Language already do. Actual: stored verbatim, console English. The same door also stores xx-YY (no such platform locale) and '' with 200, and refuses zh_CN with 400 "Locale must be a BCP-47 language tag". The console's own language switcher writes zh-CN, so only API and import writers hit it.

Mechanism (suspected)

The sys_user.locale write checks BCP-47 shape only, with no case fold; the console's locale pick is exact-match.

QA-source: #29890 · i18n.notification-localized-and-clears · observed beside the clauses