test(rest): record the MEASURED mechanism that keeps section 8 green, and correct the reading beside it

[#13538] Ablation (collapse + swallow, both restored, rest-server.ts unchanged
in the diff) recorded the list door directly:

  TOTAL outage  -> status 503, sites [2821, 4388]
  PARTIAL (1st) -> status 200, sites [4388], read carried NO organizationId

Site 2821 is resolveObjectMasker's guarded resolve, and that method early-returns
unless metaType === 'object'. So what keeps section 8 green under a swallow is a
second guarded resolve that only exists for `object` -- the same fixture choice
that makes its org-scope question vacuous. It is NOT the three-resolves-in-the-
handler reading recorded in the card and in section 8's own note: the handler's
other two resolves sit behind metaTypeSingular(...) === 'app' and === 'dashboard'
and never run for `object` at all.

The conclusion those notes drew was right; the mechanism they named was not.
Section 8's paragraph is left intact and a correction is added beside it, so the
historical record stays readable. Re-deriving by SYMBOL rather than by line is
what separated the two.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk

Author: claude

packages/rest/src/execctx-consumer-census.test.ts

@@ -629,6 +629,14 @@ describe('[#13279] §7 every caught resolveExecCtx site re-raises the outage', (
 //    door ANSWERS; §7 pins what each SITE spells. Only §7 fails on one reverted
 //    site, and that is the division of labour to keep.
 //
+//    ⚠️ [#13538] CORRECTED, by ablation, without touching the paragraph above:
+//    the mechanism named there is not the operative one. Reverting the `:type`
+//    site and driving THIS section leaves it green because `resolveObjectMasker`
+//    resolves the context again, guarded — and that method early-returns unless
+//    `metaType === 'object'`, which is exactly the type this section sweeps. The
+//    handler's 'app' and 'dashboard' resolves never run for `object`. §9 carries
+//    the measurement.
+//
 //    ⚠️ Which also names what neither section covers: a PARTIAL outage, where
 //    only the first read fails. There the swallow returns `undefined`, the
 //    handler proceeds with no `organizationId`, and the door answers the
@@ -744,6 +752,24 @@ describe('[#13279] §8 an outage at the four continuation sites is not served as
 //          both halves of that, so the reason §8 stops short stays measured
 //          instead of becoming folklore.
 //
+//    ⚠️ AND THE TWO ARE THE SAME FIXTURE, which is the part worth keeping.
+//    Ablation (collapse + swallow, both restored) recorded the list door's
+//    sites and answers directly:
+//
+//        TOTAL outage   → status 503, sites [2821, 4388]
+//        PARTIAL (1st)  → status 200, sites [4388], read carried NO organizationId
+//
+//    Site 2821 is `resolveObjectMasker`'s guarded resolve, and that method
+//    early-returns unless `metaType === 'object'`. So what actually keeps §8
+//    green under a swallow is a SECOND GUARDED RESOLVE THAT ONLY EXISTS FOR
+//    `object` — the same fixture choice that makes its org-scope question
+//    vacuous. ⛔ It is NOT the reading the card and §8's own note below record
+//    (three resolves inside the `:type` handler): the handler's other two sit
+//    behind `metaTypeSingular(...) === 'app'` and `=== 'dashboard'` and never
+//    run for `object` at all. The conclusion those notes drew was right; the
+//    mechanism they named was not, and re-deriving it by SYMBOL rather than by
+//    line is what separated the two.
+//
 //    ⇒ What is owed is therefore a changed CRITERION on §8's harness — fault
 //    selection per read, driven at an ORG-OVERRIDABLE type — not a new
 //    source-text case. This section is that criterion; §8 keeps its own subject