docs(observability-map): correct the corpus counts and drop the stale timings

Updating the workflow's entry count left three prose figures behind: the README
said 44 rewrites applied and 43 defended, and both the README and INTERNALS said
four and a half minutes. The corpus has 53 entries.

The worse one was not a count. The README claimed one hole is open when
KNOWN_GAPS has two, so the document under-reported what the corpus cannot
defend, which is the one thing it has to be honest about. The second gap,
dead-conjunction-instanceof-if, is now written out beside the first with its
reason.

Timings measured rather than scaled: the corpus step is about 1.7 minutes on
CI's runner and about 8 on a laptop, so the earlier five-minute figure in the
workflow was wrong too. Replaced the single numbers with the range, since an
exact figure is machine-dependent and nothing asserts it.

Author: 1stvamp

.github/workflows/observability-map.yml

@@ -118,16 +118,17 @@ jobs:
           } >> "$GITHUB_OUTPUT"
 
   # The tree-scale mutation corpus: every known laundering shape applied to the whole route tree,
-  # asserting the score does not rise. Roughly five minutes for 53 entries, which is why it is
-  # gated out of the package's default `pnpm test` and run here instead. Unlike the report job
+  # asserting the score does not rise. 53 entries, a couple of minutes of a runner and a good deal
+  # longer on a laptop, which is why it is gated out of the package's default `pnpm test` and run
+  # here instead. Unlike the report job
   # below it has no token to lose, so it runs for fork PRs too, and unlike the report job it is
   # allowed to fail the build.
   #
   # Gated to this package's own paths rather than running on every route pull request. What the
   # corpus measures is the TOOL's resistance to laundering, and only an edit to the tool can weaken
-  # that, so a routes-only change was paying five minutes of a 4x runner for a result that could
-  # not differ from the last one. It was also the worst kind of job to spend that on: a red x that
-  # fires on a large share of webapp pull requests, is allowed to fail, and gates nothing, which is
+  # that, so a routes-only change was paying a couple of minutes of a 4x runner for a result that
+  # could not differ from the last one. It was also the worst kind of job to spend that on: a red x
+  # that fires on a large share of webapp pull requests, is allowed to fail, and gates nothing, which is
   # the shape people learn to scroll past.
   #
   # What this gives up is real and small. A route landing a shape no corpus entry has seen can make

internal-packages/observability-map/INTERNALS.md

@@ -497,4 +497,5 @@ steps degrade to a stale report, which at least stays one comment.
 
 The corpus runs on the package's own paths and on a schedule rather than on every route pull request,
 because it measures the tool's resistance to laundering, which only an edit to the tool can weaken,
-and it costs four and a half minutes. The nightly covers tree drift late rather than not at all.
+and it costs a couple of minutes of a runner. The nightly covers tree drift late rather than not at
+all.

internal-packages/observability-map/README.md

@@ -91,7 +91,7 @@ find there.
 
 ### What stops it being gamed
 
-`src/mutationCorpus.test.ts` applies 44 semantics-preserving or handling-deleting rewrites to the
+`src/mutationCorpus.test.ts` applies 53 semantics-preserving or handling-deleting rewrites to the
 whole route tree in a temp copy and asserts three things for each: the published global does not
 rise, the mean over the routes measured in both runs does not rise, and for a semantics-preserving
 rewrite no individual route's score rises or drops out of the measured set. Every laundering shape a
@@ -102,14 +102,17 @@ score from 19 to 8, so the metric does not pay you for removing error handling.
 in `try { ... } catch (e) { throw e }` leaves the global at 19 and raises no route, so it does not
 pay you for adding error handling that does nothing either.
 
-One hole is open and the corpus says so. A catch over `try { 0; }` is refused, but `canRaise`
+Two holes are open and the corpus says so. A catch over `try { 0; }` is refused, but `canRaise`
 accepts any call, so `try { String(0); }` reads as real error handling: it takes the tree from 19 to
 44 and raises 224 routes. Telling an inert call from one that can throw needs types the scanner does
-not have. That entry, `dead-classifying-try-with-call`, runs as an expected failure with the
-residual written out beside it, so the claim is "43 rewrites are defended and here is the one that
-is not", never "unpaddable".
-
-The corpus takes about four and a half minutes, so it is gated behind `OBS_MAP_MUTATION_CORPUS=1`
+not have. The second, `dead-conjunction-instanceof-if`, is a dead condition rather than a dead arm:
+`selectsADistinctPath` folds the arm, and `literalTruth` treats `&&` as always null on purpose so a
+live guard is never read as dead, so widening that fold is a different rule needing its own
+measurement. Both run as expected failures with the residual written out beside them, so the claim
+is "51 rewrites are defended and here are the two that are not", never "unpaddable".
+
+The corpus takes minutes rather than seconds, under two on CI's runner and closer to eight on a
+laptop, so it is gated behind `OBS_MAP_MUTATION_CORPUS=1`
 and runs as its own CI job rather than in `pnpm test`. Run it if you change this package:
 
 ```bash