docs(W4): withdraw the test count from the method paragraph, do not replace it

The paragraph arguing 'run the suite before concluding a docs change has no code
consumers' carried a number: 'CI 2592 ran 1617 tests, 1 failed, 1616 passed'.
That number is wrong and is withdrawn in place rather than deleted.

Extracting per-test totals from these pipeline logs is not a reliable method:
the same regex over the same log format returns 1003 for 2592, 1022 for 2593
and 3471 for 2594, which are runs of the same suite. Three irreconcilable
answers from one method is proof the method does not measure what it claims,
so no corrected count is substituted.

The claim is restated in what the log carries reliably, the named FAIL list and
the turbo task line. The count was decoration on a claim already carried by a
specific name: one named failing spec is what refuted three hand-searches.

docs/plans/2026-08-20_w4-document-contract-worklist.md

@@ -347,9 +347,18 @@ beside it. Verified by evaluating both regexes against the real file: old `false
 Control: a page carrying `superseded-by` still fails the new regex, so the assertion still asserts
 something rather than matching anything with front matter.
 
-**The method point, which outlives this file.** CI 2592 ran 1617 tests against the stamped tree: 1
+**The method point, which outlives this file.** CI 2592 ran the whole suite against the stamped
-failed, 1616 passed. That is a stronger consumer search than any grep the three of us ran, because
+tree, 46 turbo tasks, and returned exactly one failing spec: this one. That is a stronger consumer
-it does not depend on guessing how a consumer reads the file. **Run the suite before concluding a
+search than any grep the three of us ran, because it does not depend on guessing how a consumer
+reads the file.
+
+An earlier draft of this paragraph put a test count here, "1617 tests, 1 failed". **That number was
+wrong and it is withdrawn.** Extracting per-test totals from these pipeline logs is not reliable:
+the same regex over the same log format returns 1003 for 2592, 1022 for 2593 and 3471 for 2594,
+which are runs of the same suite. Three irreconcilable answers from one method is proof the method
+does not measure what it claims. What the log does carry reliably is the FAIL list and the turbo
+task line, so the claim is stated in those terms instead. The point never needed the count: one
+named failing spec is what refuted three hand-searches. **Run the suite before concluding a
 documentation change has no code consumers.** Two independent seats and a reviewer searching by
 hand missed the one that existed.