tests(attachments): pin unscoped-multi-delete clause C3 end to end, and correct the ledger that still calls it broken - #11326

Fixes #9483

QA run #9401 listed attachments-storage.attach-requires-parent-edit clause C3 —
"an unscoped multi-delete (no id AND no where) is refused outright (#4757)" — as
unpinned. #9724 correctly declined to pin it: measured end to end, the refusal did
not fire, and pinning the behaviour of the day would have turned the eventual fix
red. That product gap (#9719) was closed by PR #9797 and widened to the update verb
by #9974.

So the first deliverable here was re-verification, not test-authoring. Walking
the card's clause list against the merged ref:

Nothing #9724 landed is re-pinned.

The ledger was wrong in the dangerous direction

automated.ref and knownGaps still read "⛔ CLAUSE 3 IS NOT PINNED … the #4757
'refused outright' rule does NOT fire through ObjectQL.delete". That has been false
since 2026-08-19. The next Tier-1 runner would have been told that a shipped, working
safety guard is broken.

The measured detection gap — why a new pin was needed at all

"Refused outright" and "the per-row gate refused one of the rows" answer with the
same code, so they are indistinguishable on a fixture whose rows split
entitled/not — which is exactly the fixture the landed block uses.

Measured, not argued: with dispatchUnscopedMultiWrite removed from both
sys_attachment registrations, service-storage rebuilt and the ablation proven
live in dist/ (ablation-dist-preflight.mjs → "marker absent from all 6 built
files"), the existing block stays 5/5 GREEN. It cannot see the clause it is
named for.

The new block seeds the one fixture that separates them — a caller who uploaded
every matched row, whom the per-row gate would wave through — plus the
empty-table (zero-match) limb, which no handler-only fix could ever reach.

Ablation (both legs rebuilt, both dist-preflighted)

Same mutation, against the extended suite: 3 failed | 7 passed, exactly as
predicted, each red for its predicted reason — a matching count alone is not a pass.

Restore leg: "marker present in 2 built files"; tree clean, src count back to 2.

Also corrected in the item

• oracle api → test, and step 6 rewritten. The step prescribed a REST probe
  the item's own knownGaps says the HTTP lane cannot express
  (DeleteManyDataRequestSchema requires an ids list, deleteManyData 把请求体的 options 展开在 where 之后 —— body 可覆盖 id 谓词,把"删这几条"放大成"删调用者可见的全部" #3897). A runner following it
  would score a schema rejection as the refusal — green for the wrong reason.
• where: {} re-documented. It reaches the same verdict by a different rule;
  the whole-operation dispatch is deliberately scoped to a delete with no where at
  all. The case now asserts the per-row message, so that boundary goes red rather
  than silently agreeing if installAttachmentAccessHooks does not authorize an UNSCOPED multi-delete: no id + no where reads as "nothing to authorize" and deleteMany runs over the whole table #4757's refusal ever widens.
• Source list: MULTI_DELETE_AUTH_LIMIT → MULTI_WRITE_AUTH_LIMIT.

Verification — union at e3da4cda (the final commit)

Test Files 1 passed (1) / Tests 10 passed (10).

Gates green, each read from its own verdict line: check:platform-checklist (15
areas, 205 items) · check:nul-bytes (6349 files) · check:engine-double-contract ·
check:where-matcher · check:test-source-alias · check:cross-package-test-inputs ·
check:type-check-coverage · check:query-options-erasure · check:doc-authoring ·
check:doc-formula-expressions · check:published-files · check:slot-lookup ·
check:type-source-resolution · check-ci-filter-parity · check-plugin-teardown-shape ·
check-affected-docs · spec check:empty-state / check:liveness /
check:strictness-ledger / check:variant-docs · @objectstack/dogfood typecheck.

check:type-check-debt --re-measure refused first on an unbuilt closure — recorded
as NOT MEASURED, then the closure was built exactly as lint.yml does and it re-ran
green: "33 ledger entr(ies) re-measured in 233.9s, 1897 raw tsc error(s) total, none
above its recorded number." No baseline moved.

ESLint narrowed to the diff and the narrowing is measured, not assumed: 2 files
submitted, --format json reports the .ts file linted with 0 errors / 0 warnings
and the .json "ignored because no matching configuration was supplied" — so eslint's
own config puts it outside the linted population. Type-aware linting is not enabled
(eslint.config.mjs states no parserOptions.project, no typed rules), so this diff
cannot move the verdict on any untouched file.

No changeset: @objectstack/dogfood is private: true and the diff is tests plus
checklist prose, so this releases nothing — skip-changeset applied, per this repo's
route 2 (an empty-frontmatter changeset is explicitly the wrong route here).

Generated by Claude Code