fix: tell a lagging read from a broken release

[JumpLink]

The v5.0.0 sweep was the first real run of the topological publisher, and it worked: measured
from the run's own log, 0 ordering defects over 7593 edges, with the only out-of-order edges
being the 11 inside the six-member cycle, open for 27 seconds. Down from 508 packages over 128
minutes.

It still ended red, over 76 closure gaps. Not one of them was a defect. Every single one named a
dependency this same run had already published — the registry simply had not caught up. Measured
on that run: @girs/matekbd-1.0 was readable 4m12s after its own publish returned success.

What was wrong

One errors counter stood for two different facts: a publish that failed, and a closure that is
not readable yet. Everything else followed from that.

✅ 110.6% - Processed: 716, Errors: 76      <- 716 + 76, the same packages twice
   📋 Total: 792                            <- there are 716
❌ 76 of 792 package(s) failed to publish   <- they published fine

A reader of that log looks for 76 broken publishes that do not exist.

What this changes

A surviving gap is classified against the plan, not the registry. Whether a gap is a defect
was never a function of how long npm is asked:

the dependency is	verdict	fatal
published earlier, or in the same group	lag	no
published later in this same run	ordering-defect	yes
not published by this release at all	not-in-release	yes

The middle row already threw before this PR; it never fired in v5.0.0, which is the independent
confirmation that the plan was right. The last row is now its own case rather than an unnamed one.

The lag budget drops from 60s to 15s. It buys quiet, not correctness — a gap that resolves
inside the window never reaches the log, and nothing else. At 60s it cost the v5.0.0 sweep roughly
an hour of its two hours: 19.2 s per package against the 10.7 s of the release before it.

Phase 3 gets the last word, so it has to run and has to be patient. It now runs whenever
nothing failed to publish (before: only when the gap count was also zero, so lag skipped it), and
it retries a resolution miss up to four times at a minute apart. That is also the fix for the three
SDK channels that published cleanly and were then reported uninstallable by this very probe,
seconds later.

Validation

• npm run check, npm test — 23 tests, 4 of them new for the classification, one asserting the
  same gap yields three different verdicts under three plans
• npm run test:e2e green, including both negative arms — the fatal paths still exit 1
• and the arm that matters for a change that makes something non-fatal: with classifyGap forced
  to return lag for everything, the e2e negative arm flips red. Without that mutation test this
  PR would be indistinguishable from one that quietly switched the gate off.

🤖 Generated with Claude Code

https://claude.ai/code/session_012KM53BXFvEdP4PLgcojKCS