fix(intake): untested invariant must subtract only classified Intake records

[x-dc-coder]

Problem

Since 928cb55 (main HEAD), every [Submission] issue preflight fails at npm run validate → check-public-site.mjs. The submission itself passes (prepare-issue-intake succeeds and creates the pending-review record + typed Harness plan; intake:check accepts the queue), but the repo-wide inventory invariant then throws, so Commit the pending-review record / Open the review PR are skipped — the record can never reach main, so no maintainer can classify it. This is a pipeline self-block, not a submission-content problem.

Tracked by #48 and #57; independently reproduced by the author of #89. Additional blocked data points: #86, #87, #90, and #91 (lab-monitor@2.0.0, 2026-08-28).

Root cause

check-public-site.mjs line 127 expects:

inventory.summary.verification.untested === catalog.packages.length - intake.records.length

but build-verification-inventory.mjs can only classify a project when the Intake record maps to a Catalog project and is in one of the three classified states (current-baseline-passed / source-evidence-passed / blocked). A newly prepared pending-review record starts in state untested and is not (yet) in the Catalog, so the expected formula counts one more subtracted record than the builder can observe. Any new submission makes the two sides differ by exactly 1, permanently.

Measured on 928cb55 with the #91 record replayed locally via node scripts/prepare-issue-intake.mjs:

catalog.packages.length = 680   intake.records.length = 12   classified records = 11
inventory untested = 669   expected = 668   → FAIL (off by exactly the 1 new untested record)

Fix

Subtract only the classified records (the same three states the builder uses). Mathematically identical to the current expectation whenever every queue record is classified (today's main), so there is no behavior change for the current tree; it only stops the false failure when a pending-review record is in flight.

-  || (inventory.summary?.verification?.untested ?? 0) !== catalog.packages.length - intake.records.length
+  || (inventory.summary?.verification?.untested ?? 0) !== catalog.packages.length
+    - intakeVerification['current-baseline-passed'] - intakeVerification['source-evidence-passed'] - intakeVerification.blocked

The gate remains strict: it still pins untested to an exact count derived from the authoritative Intake queue, and every other invariant in the block (empty Registry, transactional === 2, supplemental-only external evidence, full project coverage, capabilities present) is untouched.

Evidence

• Local replay on 928cb55 (Node 22, npm ci --ignore-scripts):
  • before fix: npm run validate fails exactly as CI does (verification inventory must cover every Catalog project…);
  • after fix: npm run check and npm run validate fully green (100 tests: 99 pass, 1 skip; public site accepted: 680 catalog entries …) with the 12th pending-review record present in the queue.
• Mutation test: tampering inventory.summary.verification.untested from 669 to 670 makes check-public-site.mjs fail (exit 1) again; restoring makes it pass. The gate still catches real desyncs.
• No authority granted: this only repairs a counting identity; Registry admission remains exclusively under registry-v1.json per INTAKE.

With this in place the intake workflow can commit the pending-review record and open the review PR for #91 (and every other blocked submission), after which the normal human trust review and current-baseline verification proceed unchanged.