docs(spec): the 17.4.0 entry no longer records the paid packages/rest follow-up as owed (#21014)

Fixes #18858

Clause-②: no

## What

`packages/spec/CHANGELOG.md`, inside the released `@objectstack/spec`
17.4.0 entry for 094b8fd, closed its `batch.maxBatchSize` note with "it
is owed to a follow-up in `packages/rest`" and anchored the quoted
docblock at `packages/rest/src/rest-server.ts:2071`. Both are false
today, and the first was already false when it was published:

- ec5db7b (PR #16942) paid that follow-up. It rewrote
`enforceBatchSize`'s docblock to call the cap embedder policy. It landed
2026-09-08T18:05Z, eleven hours after 094b8fd (06:54Z), and shipped in
`@objectstack/rest` 17.4.0, the same release as the note. The npm
registry's `time` field shows spec 17.4.0 published at
2026-09-09T03:57:51Z and rest 17.4.0 at 03:58:13Z.
- `:2071` was correct at 094b8fd and has drifted since. At `a5bce4088`
that line is JSDoc on `resolveRequestEnvironmentId`.

This PR amends that one entry in place. It uses the shape this file's
own errata already use (`*Erratum, DATE — … (Corrected after
publication, #N.)*`, six instances in this file). The closest is the
2026-09-18 batch-cap erratum on the same subject, which puts the line at
the end of the entry and says how many passages above it were corrected
in place:

1. The passage now anchors the quotation by symbol (the
`enforceBatchSize` docblock of `packages/rest/src/rest-server.ts`)
instead of by line number. Its last clause names ec5db7b as the
follow-up that was paid.
2. One dated erratum line closes the entry and quotes both old
phrasings.

No other sentence in the entry is touched. This PR has no changeset. The
`packages/*/CHANGELOG.md` row of the AGENTS.md Documentation Guardrails
says a factual error in a released entry is amended in place in a
docs-only PR. A changeset would compile the correction into a new
release note, which is the erratum-in-a-later-entry shape that row rules
out. The amended text reaches npm with the next `@objectstack/spec`
tarball.

## Evidence (measured on `a5bce4088`, this branch's base)

| Reading | Result |
|---|---|
| `grep -c "deployment policy" packages/rest/src/rest-server.ts` | 0.
Positive control `grep -c maxBatchSize` on the same file: 6. The
docblock now reads "⛔ It is NOT deployment policy", but a line break
splits that phrase, so the single-line grep cannot match it. Its text
was read directly as well. |
| `packages/rest/CHANGELOG.md` | `ec5db7b` occurs once, under `##
17.4.0` / `### Patch Changes` |
| npm tarballs `@objectstack/spec` 17.4.0 and 17.5.0 | the "owed to a
follow-up" sentence is in each `package/CHANGELOG.md` once, under `##
17.4.0` |
| npm tarballs `@objectstack/rest` 17.4.0 and 17.5.0 | the `ec5db7b`
entry is in each once, under `## 17.4.0` |
| `git show 094b8fd:packages/rest/src/rest-server.ts`, line 2071 | "The
cap is deployment policy — …", so the anchor was correct when it was
written |

## Gates (on `efea2a386e`, the final commit)

`node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
--commands` derived 55 commands for this one path. 51 ran and exited 0.
They include `pnpm check:nul-bytes`, `pnpm check:issue-citations`, `pnpm
check:published-files`, `pnpm check:release-notes`, `pnpm
check:release-page-status` and `node
scripts/check-release-section-coverage.mjs --strict`. The `--ran`
reconciliation reads: 55 accounted for, 51 run, 4 NOT-MEASURED, 0 UNRUN.

NOT MEASURED (4): `check:dts-closure`, `check:dual-build-cjs-loads`,
`check:lean-entry-closure` and `check:sourcemap-no-sources-content`.
Each exited 3 with PREREQUISITE NOT MET. They read the `dist/` of every
workspace package, and this worktree has no workspace build. A CHANGELOG
prose edit changes no build input, and CI runs these gates over a fresh
build.

`check:issue-citations` passes, but `**/CHANGELOG.md` is one of its
declared deferred surfaces, so it did not judge the new `#18858`
citation. That citation was checked by hand: REST `GET /issues/18858`
answers 200, and the item is an issue, not a pull request.

## Acceptance notes

- The entry's bold lead ("really does describe itself as deployment
policy") and its "it exists verbatim in the REST server" are in the
present tense. They describe the tree 094b8fd landed on. Following the
card's scope, they stay as written, and the erratum line records that
the docblock was rewritten in the same release.
- The card cites the passage at `:3581`, read at `631dcbd4b`. At
`a5bce4088` it is at `:18471`, because later release sections were added
above it.

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

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

Author: objectstack-fleet[bot]

packages/spec/CHANGELOG.md

@@ -18468,9 +18468,11 @@
 
   ⚠️ **A correction to the record this change is built on.** An earlier draft of these sentences named a second door, `createHonoServerPlugin({ restConfig })`. No such function exists — a definition probe returns zero across the tree, against a positive control that finds `createRestApiPlugin` at `packages/rest/src/rest-api-plugin.ts:115`. `HonoServerPlugin` is a class that declares a `restConfig?: RestServerConfig` option whose single reader takes `api.basePath` for the SPA fallback; it never constructs a REST server, so it is not a door onto any of these keys. The claim was inherited from prose that was already in the tree, and on a card whose whole subject is a declared posture nobody can reach, publishing a declared door that does not exist would have been the same defect one level up. Every place this change touches now says the corrected thing.
 
-  ⚠️ **`batch.maxBatchSize` really does describe itself as deployment policy — in another package.** The phrase does not occur in `packages/spec/src/api/rest-server.zod.ts`, but it exists verbatim in the REST server: *"The cap is deployment policy — `RestServerConfig.batch.maxBatchSize` (1..1000, default 200)"* at `packages/rest/src/rest-server.ts:2071`. Same defect class, different package, and not touched here — it is owed to a follow-up in `packages/rest`.
+  ⚠️ **`batch.maxBatchSize` really does describe itself as deployment policy — in another package.** The phrase does not occur in `packages/spec/src/api/rest-server.zod.ts`, but it exists verbatim in the REST server: *"The cap is deployment policy — `RestServerConfig.batch.maxBatchSize` (1..1000, default 200)"* in the `enforceBatchSize` docblock of `packages/rest/src/rest-server.ts`. Same defect class, different package, and not touched here — the follow-up in `packages/rest` is ec5db7b, which rewrote that docblock to call the cap embedder policy and shipped in `@objectstack/rest` 17.4.0, the same release as this entry.
 
   No behaviour changes and no schema shape changes — no key, default, bound or refusal moves, so the accept set is byte-identical. This is prose plus ledger rows, and the regenerated `content/docs/references/api/rest-server.mdx` that follows from the `describe()` edits.
+  
+  *Erratum, 2026-10-01 — this entry anchored the REST server's "deployment policy" sentence at `packages/rest/src/rest-server.ts:2071` and closed "it is owed to a follow-up in `packages/rest`". The follow-up was paid before this entry was published: ec5db7b landed eleven hours after this change, rewrote `enforceBatchSize`'s docblock to say the cap is embedder policy, not deployment policy, and shipped in `@objectstack/rest` 17.4.0. The sentence was true when written. One passage above is corrected in place; the finding it records and everything else this entry published are unchanged. (Corrected after publication, #18858.)*
 - aedbaef: `POST /sign-up/email` for an address that already has a `sys_user` row is refused explicitly, instead of answering 200 for a row that is never written (#15587)
 
   **This is a wire-behaviour change on one lane**: a call that answers `200 {"token":null,"user":{…}}` today answers `422 USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL` after this change. Nothing is newly admitted — the response that changes is one that reported a creation that never happened.