docs(i18n): document inline I18nLabel locale maps in the translations guide

[claude]

Fixes #15984

content/docs/ui/translations.mdx is the user-facing guide for localising an
app, and read end to end it described exactly one localisation route: a
plain-string label, translated in a bundle addressed by convention. It never
mentioned the second authorized form of an I18nLabel — the inline locale map,
label: { en: 'Members', 'zh-CN': '成员' }.

That omission used to cost an author nothing observable. It no longer does: the
coverage gate now reads a map's own locales, so an author who writes
{ en, 'zh-CN' } on a stack declaring supportedLocales: ['en', 'zh-CN', 'ja-JP']
gets a real missing translation for locale "ja-JP" finding about a prop this
page gave them no vocabulary for.

What changed

One file, two additions, no restructuring:

• A row in "What you can translate" for a label written as an inline locale
  map. Its "where it lives in the bundle" cell is the point of the row:
  nowhere — the map is written on the metadata and resolved at render time.
• A bullet in "Current boundaries" carrying the four statements in order:
  both forms are authorized; the map is rendered but never extracted, so a
  translator working from the bundle will not find those strings; coverage
  counts the locales the map carries and reports the ones it omits against
  supportedLocales; and no bundle key exists for a map, nor is one
  synthesised from a node's position in the component tree — transcribed as
  the settled refusal it is (maintainer ruling 2026-09-03, Inline I18nLabel maps are invisible to os i18n extract and check:i18n-coverage — should the extractor and the coverage gate see them? (objectstack#14412 ruling A follow-up) #14749), not as a
  "not yet".

The sentence the passage is built around is rendered but never extracted: two
tools treat the same prop differently and both are right — the coverage gate
reports what the author did and did not write, while the extractor refuses to
invent a key that a later reordering of two sibling components would silently
reassign.

The page's existing "inline label:" mentions (:159, :254, :264) are
about a plain-string label as source text and are untouched.

Sources transcribed

• packages/cli/src/utils/i18n-extract.ts header — "Inline locale maps are NOT
  extracted — and are not 'unauthored' either", where the Inline I18nLabel maps are invisible to os i18n extract and check:i18n-coverage — should the extractor and the coverage gate see them? (objectstack#14412 ruling A follow-up) #14749 Q3 = C3 refusal
  and the Q2 = B1 coverage record live.
• packages/spec/src/ui/i18n.zod.ts — I18nLabelSchema, the union of a plain
  string and an inline locale map, and the note that both are real and neither
  is deprecated.
• packages/cli/src/utils/i18n-coverage.ts — the tag-matched lookup that makes
  a carried locale covered and an omitted one a gap.

No source file paths are linked from the page itself; docs link pages, not code.

Premise re-verified on the fresh tree

• 'zh-CN': appears once on the page, at :38, followed by { — bundle-file
  structure, not an inline map. The page genuinely showed the second form
  nowhere.
• locale map appeared zero times on the page before this change.

Verification

skip-changeset: content/docs/** publishes nothing from any package.

Gates run locally are listed in the report on the issue. pnpm lint and the
full gate farm are CI's run.

---

Generated by Claude Code