docs(ui): state what happens when a nav contribution names an anchor that is not there

The Setup app page explains the shell/anchor mechanism — the shell publishes
empty group anchors and capability plugins contribute into them — but stopped
short of the failure the anchor id makes possible. A contributor cannot see the
shell's ids at authoring time, so a typo is undetectable from its own source,
and the platform relocates rather than refusing: the menu renders, a smoke test
passes, and the entry has moved one level up.

Documents the rule and the diagnostic that now reports it: the `warn`-level
`nav_contribution_group_missing`, the per-app `getAppNavDiagnostics` reader, and
the `os build --json` `navigationGroupDiagnostics` key — following the
`bodyExtractionWarnings` precedent, which documents a build-only JSON key on the
page that owns the behaviour rather than in a CLI schema dump.

No hand-written page was falsified by the code change; this fills a gap rather
than correcting an error. The `packages/spec` describe() for the key has the
same gap and is filed separately — that string is embedded in ~14 generated
artifacts, so it belongs in its own PR.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UHvF5hyiZjnCyExFnfQB8m

Author: claude

content/docs/ui/setup-app.mdx

@@ -17,6 +17,35 @@ group id + priority on read, so the rendered menu reflects exactly which
 capability plugins are loaded — a disabled capability contributes nothing
 and its slot stays empty.
 
+### When a contribution names an anchor that is not there
+
+Aiming at a `group` id the target app does not declare is **not** refused and
+the entry is **not** dropped: the items are appended at the app's **top level**
+and the merge continues. That is deliberate — the merge is a read-time fold
+precisely so registration order does not matter (a contributor may register
+before the app it aims at), and a contribution into an *optional* anchor has to
+keep working when the plugin owning that anchor is not loaded.
+
+It is, however, **loud**. The relocation emits a
+`nav_contribution_group_missing` diagnostic at `warn` — naming the contributing
+package, the target app, the missing group id and the relocated items — so it
+survives `OS_REGISTRY_LOG=warn` and appears in boot output. The same finding is
+carried on the app itself, readable as
+`registry.getAppNavDiagnostics(appName)`, and it is raised once per distinct
+mis-aim rather than once per read of the app.
+
+`os build` answers the same question at compile time whenever the contributing
+package and the target app are composed into one artifact, printing the finding
+and carrying it in `--json` under `navigationGroupDiagnostics` (an empty array
+when every contribution resolved). It **reports** there; it does not fail the
+build.
+
+⚠️ The anchor id is the whole contract between a shell and its contributors,
+and a contributor cannot see the shell's ids at authoring time. A typo
+therefore produces a menu that renders, passes a smoke test, and has silently
+moved the entry one level up — which is why the diagnostic exists rather than a
+refusal.
+
 The app itself ships from the dedicated `@objectstack/setup` package
 (package id `com.objectstack.setup`), which registers it at runtime. Per
 ADR-0048 (one app per package), `/apps/setup` — resolvable as