docs(spec): state the one resolution order for a navigation entry's label (#20875)

Closes #20849

Clause-②: no (description text and a pin; the key stays
`I18nLabelSchema`, optional, and no accept set moves)

`BaseNavItemSchema.label`'s JSDoc and describe now state one resolution
order. First comes the id-keyed bundle entry that `translateApp` applies
at `/meta`, over the app's `navigation` tree (not `areas`). Else a
present label as authored: its inline locale map's value for the locale,
else its text. Else, when the label is absent, render-time inheritance
from the target. A present label is never replaced by its target's label
and never translated by matching its text.

- **Pin:** new
`packages/spec/src/system/i18n-resolver.nav-label-identity.test.ts`, 3
tests, green at `cefd0de416`.
- **Ablation:** I made `translateApp` also translate by text, in two
variants. (A) takes the target's translation when the label equals the
target name. (B) takes a nav key spelled like the text. In both, the
no-id-key case went red and the id-key case stayed green. Restore was
proven: blob `1e7995c1148d` equals HEAD and `git diff HEAD` is empty.
- **Regenerated:** `content/docs/references/ui/app.mdx`, via `gen:docs`
(45 table rows). No other tracked artifact carries this describe. The
metadata-forms bundles are registry-driven, not describe-driven.
- **Local runs at `f2fe3da47d`:**
  - spec `test`: 579 files, 17069 tests passed.
  - spec `typecheck`: green, and the test program lists the new file.
  - `check:generated`: all 15 artifacts up to date.
- Derived gates: 108 derived, 106 exited 0, 0 unrun. 2 are NOT MEASURED:
`check:dual-build-cjs-loads` and `check:type-check-debt`, whose
prerequisite is a full workspace build.
- eslint on the 2 touched TS files: 0 findings. The config enables no
type-aware rules, so the untouched files' verdicts cannot move.

## Acceptance notes
- The objectui renderer at `846cec0efe` still translates a present label
that equals its target's name (`isCustomized`). It also does not resolve
an inline locale map on a nav entry, because `resolveLabel` reads only
the keyed form. The renderer half is objectui#11201's.
- `translateApp` never walks `areas[].navigation`, so the describe
scopes the bundle step to `navigation`. The translation-reference lint
still accepts area entry ids as keys.
- `translateApp` also applies an id key to an entry whose label is
absent. That is why the bundle step is listed first.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01Sfe5YjBLwB9J3y8fvm2xq1)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

.changeset/nav-item-label-resolution-order.md

@@ -0,0 +1,18 @@
+---
+'@objectstack/spec': patch
+---
+
+docs(spec): a navigation entry's `label` describe states the one order the label resolves in
+
+Clause-②: no
+
+The `label` of a navigation entry (`BaseNavItemSchema`) said a present label "renders
+verbatim and is never overwritten", which, read literally, forbids the id-keyed localization
+`translateApp` already performs at the `/meta` boundary. Its describe and JSDoc now state one
+order: the bundle entry `apps.<app>.navigation.<id>.label` for the active locale chain, keyed
+by the entry's `id` and applied by `translateApp` over the app's `navigation` tree (not
+`areas`); else a present label as authored — its inline locale map's value for that locale,
+else its text; else, when absent, the current label of what the entry opens, at render time,
+localized by the target's own translation. A present label is never replaced by its target's
+label and never translated by matching its text. No accepted shape changes: `label` stays an
+optional `I18nLabel`.