docs(cli): correct the issue citation and reconcile the flake counts

Review findings on #327, both about the comment rather than the test.

The comment said this race was asserted "until #262 work
looked at it", which cites the wrong issue for the work this PR is doing.
#262 reports two subprocess-spawning tests in error-envelope.test.ts and
verify-test-commands.test.ts, a different failure mode, and never names
this one — the PR body says as much, so the comment contradicted it. A
future reader would have opened #262 and found nothing connecting it to
this fixture. The citation is kept rather than dropped, because the causal
chain is real: #262 is where the search started, not what it found.

The comment also said the sibling failed "twice across 13 full-suite runs"
while the sibling's own comment, unchanged, says "once across four
concurrent full-suite runs". Both are true and neither was wrong: they are
two measurement passes, the first while #323 was open and the second
counting captured logs recovered later. Nothing said so, which left two
comments appearing to disagree about the same event.

Author: thecodedrift

packages/cli/test/vale-run.test.ts

@@ -259,17 +259,29 @@ withVale("runVale against the real binary", () => {
 
   it("terminates and reports a timeout rather than hanging", async () => {
     // THE BUDGET AND THE INPUT ARE BOTH LOAD-BEARING. This asserted the winner
-    // of a race until taskless/cli#262 work looked at it: a 1ms budget against
-    // a one-line document, on the stated grounds that "1ms cannot survive
-    // process startup". That is not something the test controls. Vale runs in
-    // its OWN process and does not care whether our event loop is free, so
-    // under load the timer's callback is delayed while the child keeps going,
-    // and the run completes cleanly where the test demanded a timeout.
+    // of a race until taskless/cli#327: a 1ms budget against a one-line
+    // document, on the stated grounds that "1ms cannot survive process
+    // startup". That is not something the test controls. Vale runs in its OWN
+    // process and does not care whether our event loop is free, so under load
+    // the timer's callback is delayed while the child keeps going, and the run
+    // completes cleanly where the test demanded a timeout.
+    //
+    // NO ISSUE EVER FLAGGED THIS TEST. It was found while investigating
+    // taskless/cli#262, which reports a different flake entirely — two
+    // SUBPROCESS-SPAWNING tests in `error-envelope.test.ts` and
+    // `verify-test-commands.test.ts` — and does not name this one. #262 is
+    // where the search started, not what it found, and it remains open.
     //
     // Its sibling in `ValeRunOutcome.blocking` had the identical shape and was
-    // MEASURED failing that way — twice across 13 full-suite runs, reporting
-    // `status: "ok"` — before it was given a real margin. This test survived
-    // only because its window was narrower, not because it was safe.
+    // MEASURED failing that way, reporting `status: "ok"`, before it was given
+    // a real margin. This test survived only because its window was narrower,
+    // not because it was safe.
+    //
+    // TWO SEPARATE MEASUREMENT PASSES COUNTED THAT SIBLING, which is why the
+    // numbers here and in its own comment below differ and neither is wrong.
+    // The first, while #323 was open, saw it lose ONCE ACROSS FOUR concurrent
+    // full-suite runs. The second, counting a set of captured logs recovered
+    // later, saw TWICE ACROSS 13. Same test, same failure, different samples.
     //
     // The metric that matters is the ABSOLUTE margin (duration minus budget),
     // not a ratio: what has to happen is the child finishing before a delayed