docs(spec): regenerate api/rest-server reference for the corrected reachability prose

Claude-Session: https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/references/api/rest-server.mdx

@@ -24,24 +24,41 @@ Architecture alignment:
 
 WHO CAN WRITE THIS CONFIG (#15543) — read this before planning a deployment
 around any key below. A `RestServerConfig` is the ARGUMENT a host passes when
-it constructs the server: never a stack collection member, never a stored
-metadata row, never a file the CLI reads. Both doors are programmatic —
-`createRestApiPlugin({ api })` (`packages/rest/src/rest-api-plugin.ts`) and
-`createHonoServerPlugin({ restConfig })`
-(`packages/plugins/plugin-hono-server/src/hono-plugin.ts`).
-
-No shipped boot path opens either door with a config of its own. `os serve`
-(`packages/cli/src/commands/serve.ts`) constructs the plugin with a fixed
-argument carrying exactly two CLI-derived keys — `api.enableProjectScoping`
-and `api.projectResolution` — and the dev plugin
+it constructs the server: never a stack collection member and never a stored
+metadata row.
+
+There is exactly ONE door, and it is programmatic:
+`createRestApiPlugin({ api })` (`packages/rest/src/rest-api-plugin.ts`),
+whose `start()` is the only non-test site that reaches `new RestServer(...)`.
+⚠️ `HonoServerPlugin` (`packages/plugins/plugin-hono-server`) declares a
+`restConfig?: RestServerConfig` option, but it is NOT a second door: its one
+reader takes `api.basePath` for the SPA fallback, and that plugin never
+constructs a REST server, so nothing below `api.basePath` reaches anything.
+
+No shipped boot path opens that door with a config of its own. `os serve`
+(`packages/cli/src/commands/serve.ts`) reads the stack config's own top-level
+`api:` block and forwards exactly two keys out of it —
+`api.enableProjectScoping` and `api.projectResolution` — into a fixed
+argument, through an `as any` cast; the dev plugin
 (`packages/plugins/plugin-dev/src/dev-plugin.ts`) calls
-`createRestApiPlugin()` with no config at all. So on a CLI-started deployment
-every OTHER key here is EMBEDDER-ONLY: the whole of `crud`, `metadata` and
-`batch`, and the rest of `api`. Its value is whatever the `.default()` below
-says, and no flag, env var or config file moves it. That is the recorded
-posture, not a gap awaiting a fix: the keys keep their runtime reads and
-their embedder consumer, and the reachability answer ADR-0049 asks for is
-written per key in the liveness ledger
+`createRestApiPlugin()` with no config at all. So the CLI does read a config
+file — it just forwards those two keys and nothing else.
+
+⇒ On a CLI-started deployment every OTHER key here is EMBEDDER-ONLY: the
+whole of `crud`, `metadata` and `batch`, and the rest of `api`. Its value is
+whatever the `.default()` below says, and no flag, config file or CLI option
+moves it.
+
+⚠️ ONE CARVE-OUT, and it is the security-relevant key: the REST server's
+`normalizeConfig` folds the environment into the effective value of
+`metadata.maskObjectFields` — `OS_ALLOW_UNMASKED_OBJECT_METADATA` turns the
+ADR-0106 D8 mask OFF for a deployment that cannot otherwise reach the key.
+That env var is the only thing outside an embedder's argument that changes
+any value here. See `maskObjectFields` below.
+
+This is the recorded posture, not a gap awaiting a fix: the keys keep their
+runtime reads and their embedder consumer, and the reachability answer
+ADR-0049 asks for is written per key in the liveness ledger
 (`packages/spec/liveness/crud_endpoints.json`, `metadata_endpoints.json`,
 `batch_endpoints.json`).