docs(api): catalog the /meta unrecognised-type-spelling refusal (#9245)

The `metaUrlSpellingRefusal` envelope — `INVALID_REQUEST` / 400 / "not a
recognised spelling" — ships on the wire and was documented nowhere in
`content/docs/**`. A caller that hit it got a status and a code it could not
look up. Adds the catalog entry, plus a pointer from the Metadata API page.

Measured on origin/main rather than inherited: the refusal declines a
MISSPELLING of a declared type (`viewes` for `view`), not a plural —
recognised plurals fold to the canonical singular and are served. The entry
states no verb count, because a prose count is a declared-vs-enforced pair
with no enforcement.

Fixes #9193


Claude-Session: https://claude.ai/code/session_01Y26DJEHSBhhAQ6wwfsHNza

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

Author: os-project-manager

content/docs/api/error-catalog.mdx

@@ -521,6 +521,62 @@ if (!res.success) showToast(res.error);
 
 ---
 
+## Metadata API Errors (`/meta`)
+
+`/meta` refusals carry codes registered to `@objectstack/metadata-protocol` in the
+[error-code ledger](/docs/references/api/error-code-ledger), not the standard catalog
+above — so their status is published here rather than inherited from a category. This
+section documents the **type-spelling** refusal the `/meta` request boundary raises. It
+is not a complete inventory of `/meta` errors.
+
+### `INVALID_REQUEST` — unrecognised type spelling
+
+**Cause:** The type segment of a `/meta` path is not a spelling ObjectStack recognises,
+*and* it evidently reaches for a metadata type the platform itself declares — a
+misspelling of a real type. `GET /meta/viewes` is refused because `viewes` is not a
+recognised spelling of the declared type `view`.
+
+**Fix:** Address the type by its canonical singular name, or by its canonical REST
+plural. The refusal names both, so the correction never has to be guessed — for
+`viewes` it names `view` and `views`. See the [Metadata API](/docs/api/metadata-api).  
+**Retry:** `no_retry` — the spelling is refused deterministically; retrying it
+unchanged returns the same `400`.
+
+`GET /api/v1/meta/viewes` answers `400` with:
+
+```json
+{
+  "success": false,
+  "error": {
+    "code": "INVALID_REQUEST",
+    "message": "[invalid_request] 'viewes' is not a recognised spelling of metadata type 'view'. Address it as 'view' or 'views'. Refused rather than treated as a plugin-registered type, because forwarding an unrecognised spelling of a declared type would create a second namespace under type='viewes'.",
+    "httpStatus": 400
+  }
+}
+```
+
+<Callout type="warn">
+**This is not a refusal of plural type names.** Recognised plurals are *not* refused:
+the boundary folds them to the canonical singular and serves the request — `views`
+addresses `view`, `objects` addresses `object`. What this error refuses is a spelling
+that resolves to no type at all while reaching for one the platform declares.
+</Callout>
+
+**Why it is refused rather than passed through.** A type segment the platform does not
+recognise would otherwise be treated as a plugin-registered kind, and a write under it
+would mint a second metadata namespace keyed by the misspelling — `type='viewes'`
+alongside `type='view'` — which nothing reads and nothing serves. Refusing at the
+boundary is what keeps one type to one key.
+
+⛔ **Not this error:** a segment that reaches for no declared type — `/meta/fieldz`, or
+a plugin-registered kind such as `theme` — is not a misspelling of anything the platform
+declares, so this rule stays silent and the request continues down the plugin path. A
+**write** whose segment is not a metadata type at all is refused separately: same
+`INVALID_REQUEST` code and `400` status, different message (*"… is not a metadata
+type"*). Tell the two apart by the message, not the code.
+
+---
+
 ## Error Response Structure
 
 Every error response follows the `EnhancedApiError` schema:

content/docs/api/metadata-api.mdx

@@ -11,6 +11,11 @@ Manage object schemas, metadata types, UI views, and installed packages over RES
 
 Retrieve and manage object schemas, metadata types, and UI views. Always available — provided by the kernel.
 
+A type segment these routes cannot recognise, but which reaches for a metadata type the
+platform declares, is refused `400 INVALID_REQUEST` rather than served — see
+[unrecognised type spelling](/docs/api/error-catalog#invalid_request--unrecognised-type-spelling)
+in the error catalog for the envelope and the correction it names.
+
 ### `GET /meta`
 
 List all registered metadata types.