rest/meta: the `?type=` diagnostics call site still tells the next reader that `getMetaItems` applies no registry gate — true when it was written, false since #14767

[os-trump]

Filed by the domain:cli execution seat immediately after PR #14677 merged, as that PR's own body asks. ⛔ Not a defect in #14677 — it is the residue #14677 deliberately declined to resolve inside a merge, and said so in writing rather than quietly rewriting its own record.

The stale claim

packages/rest/src/rest-server.ts carries a call-site comment beside the GET /meta/diagnostics ?type= arm (locate by symbol, near the organizationIdForMetaRead(canonicalMetaUrlType(diagnosticsType), …) call — line numbers in this file rot within the day; it was ~:4574 on #14677's head) whose load-bearing sentence is that getMetaItems applies no registry gate of its own, so the scope of a sweep is decided per type, by the caller.

That was measured and true on the tree #14677 was written against. It is false on today's main:

• fix(metadata-protocol): apply the allowOrgOverride read gate inside getMetaItems, so multi-type sweeps are scoped per type #14767 put organizationIdForMetaRead(request.type, request.organizationId) inside getMetaItems itself, after the canonical type fold — which is, almost verbatim, the proposal rest/meta: state the caller's organization on the /meta/diagnostics ?type= sweep #14677's body made and declined to apply.
• fix(metadata-protocol): gate getMetaItem's overlay read on the metadata registry #14908 then added a second such site in protocol.ts, for the singular getMetaItem overlay read.

So a reader who trusts the comment will believe the door is the only thing folding the type, when there are now two more folds one layer down.

What is NOT wrong

The behaviour is unaffected and the door-side predicate is still correct. organizationIdForMetaRead answers either its argument or undefined, so a second application over the same type is idempotent, and both applications fold the identical string. Nothing to repair at runtime; #14677 pinned that and its ablation A still reddens exactly the six repair cases on the merged tree.

The unit of work

One design question, then one edit:

1. Is the door-side predicate defence in depth, or is it now redundant? Deliberate answer required — it is not a merge resolution, which is exactly why rest/meta: state the caller's organization on the /meta/diagnostics ?type= sweep #14677 refused to decide it under merge pressure. Defence-in-depth argues for keeping it and rewriting the comment to say why it is doubled; redundancy argues for deleting it and letting the inner gate own the fold. ⚠️ Whoever answers should note the two are not symmetric: deleting the door-side call makes getMetaItems' internal gate load-bearing for a REST door, which no pin currently states.
2. Either way the comment must stop asserting the falsified sentence — it is the only artefact in the tree that still says it.

Acceptance

• The call-site comment describes today's tree, and names the inner gate(s) it now sits above.
• If the door-side predicate is removed, a pin states that the ?type= arm still folds — rest/meta: state the caller's organization on the /meta/diagnostics ?type= sweep #14677's ablation A is the ready-made harness (packages/rest/src/rest-server-meta-read-org-scope.test.ts), and it must keep reddening on a mutation that drops the organization.
• If it is kept, no pin change is owed; the comment carries the reason.

Fences

• ⛔ packages/spec — read only.
• ⛔ packages/rest/src/error-response.ts — single writer, rest: classifyDataError's structured-code arms ship the QuickJS debug wrapper as error for a sandboxed producer — the mirror of #11588, on the door #11588 did not touch #14704.
• ⛔ content/docs/releases/ — never in a code PR.
• protocol.ts in @objectstack/metadata-protocol belongs to another seat; if the answer is "remove the inner gates", that is not this card — file it there.

Provenance

PR #14677 (Part of #13753), merged 2026-09-03T17:52:45Z. Its body, section "What the merge brought in, and the one number it moved", point 1, states the supersession and records that nothing was rewritten to match. Ablation B in that PR went from 1 failed / 29 passed to 0 failed / 30 passed for this same reason — the phantom-row control is now held in two places, so it no longer discriminates the call site.