docs: correct the hand-written pages that still taught the retired keys (#4667)

The generated `content/docs/references/**` pages regenerate themselves; these
six sites are hand-written and had to be read.

- `ui/apps.mdx` documented `homePageId` in the property table, named it in the
  prose explaining why nav `id` is required, and authored it in the worked
  example. The same table also still advertised `objects`, `apis` and
  `mobileNavigation` — three keys #4142 retired, whose rows had outlived them.
  All four rows go; leaving a table that documents keys the schema now rejects
  is the docs half of the same defect this campaign exists to remove.
- `ui/translations.mdx` had already noticed the problem — it listed
  `validationMessages` under "Current boundaries" as having no runtime consumer
  — but described it as a gap to be filled rather than a key to stop writing.
  Rewritten to point at `object.validations[].message`.
- `protocol/kernel/i18n-standard.mdx` authored the group in its worked bundle
  and named it in the coverage-checking prose.

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

Author: claude

content/docs/protocol/kernel/i18n-standard.mdx

@@ -193,7 +193,6 @@ const zh: TranslationData = {
   pages: { landing: { title: '欢迎' } },
   globalActions: { export_csv: { label: '导出 CSV' } },
   messages: { 'common.save': '保存' },
-  validationMessages: { 'discount_limit': '折扣不能超过40%' },
 };
 ```
 
@@ -841,7 +840,7 @@ options: { 'Direct Mail': '直邮' }  // ❌ keyed by the label — never resolv
 options: { 'direct-mail': '直邮' }  // ❌ a variant spelling of the value
 ```
 
-`messages`, `validationMessages`, `settings`, `settingsCommon` and
+`messages`, `settings`, `settingsCommon` and
 `metadataForms` are **not** checked: their keys are owned by application code,
 plugins, and the platform's own metadata-type registry rather than by this
 stack's metadata, so there is no set of legal names to resolve against.

content/docs/ui/apps.mdx

@@ -50,10 +50,6 @@ const crmApp = {
 | `navigation` | `NavigationItem[]` | optional | Navigation tree |
 | `branding` | `AppBranding` | optional | Visual customization |
 | `requiredPermissions` | `string[]` | optional | Required permissions to access |
-| `homePageId` | `string` | optional | ID of the navigation item to serve as the landing page |
-| `objects` | `unknown[]` | optional | Objects belonging to this app |
-| `apis` | `unknown[]` | optional | Custom APIs belonging to this app |
-| `mobileNavigation` | `object` | optional | Mobile-specific navigation |
 
 ## Navigation Items
 
@@ -181,7 +177,8 @@ label — the only keys it accepts are `type`, an optional `id`, and an optional
 
 All navigation items **except `separator`** share these base properties. Every
 item **must** declare a unique `id` (lowercase `snake_case`) — it is required by
-the schema and is referenced by `homePageId` and `mobileNavigation.bottomNavItems`.
+the schema, and it is what `order` sorts and what the landing page resolves to
+(the first item, since `homePageId` was removed in 17.0.0 — see below).
 (On a `separator`, `id` is optional and the remaining properties below are
 rejected — a divider has nothing to label, gate, or badge.)
 
@@ -286,7 +283,9 @@ const projectApp = {
   ],
 
   requiredPermissions: ['pm_access'],
-  homePageId: 'nav_home',
+  // No `homePageId`: the landing page IS the first navigation item (by `order`),
+  // and the ROOT landing follows `isDefault`. The key was removed in 17.0.0 (#4667)
+  // because nothing ever read it.
 };
 ```
 

content/docs/ui/translations.mdx

@@ -235,9 +235,11 @@ up-to-date bundle re-extracts byte-identically.
 
 Honest limits worth knowing before you plan around them:
 
-- **`validationMessages` has no runtime consumer today.** The schema accepts it
-  and the coverage tooling counts it, but nothing reads it back — validation
-  errors are not translated through bundles yet.
+- **Validation messages are not translated through bundles.** The
+  `validationMessages` group was removed in 17.0.0 (#4667): it had no runtime
+  consumer, so a translated rule message was stored and never shown. Author the
+  message on the rule itself (`object.validations[].message`), which the engine
+  returns on every rejected write.
 - **No ICU MessageFormat** — plural/gender formatting isn't available;
   interpolation is always simple `{variable}` substitution.
 - **Runtime authoring is process-wide.** The authored layer is synced across all