fix: triage reported its own failures as work waiting for a maintainer

[sjh9714]

What a first-time user actually got

Running the command exactly as the README documents it, on a public repository,
with no token:

20 open pull request(s) read. 14 have something a maintainer checks by hand.

#10586  gci-fun-1                    could not be read
#12046  feat/detect-nested-any-in-…  could not be read
#12086  strict-void-return-fixer     could not be read
...

With a token, the same repository returns five rows. Nine of those fourteen
were not pull requests needing attention. They were GitHub refusing the request:
60 unauthenticated requests an hour, which one queue uses up.

Why it happened

Every failure became notes: ["could not be read"], which is the same shape a
finding has. So an unreadable pull request was counted in the headline, sorted
among real findings, and the process exited 0.

This repository states that it fails closed rather than presenting a partial
pass, and ships an ANALYSIS INCOMPLETE state for exactly this situation. The
command people are told to run first was the one place that ignored it.

What changed

• Unreadable pull requests are tracked separately from findings, reported on
  their own line, excluded from the count, and the run exits non-zero.
• When nothing could be read at all, that goes to stderr instead of a
  description of a queue the tool never saw.
• An exhausted quota stops the loop rather than attempting every remaining pull
  request, since they fail identically.
• The advice differs by cause: set GH_TOKEN when unauthenticated, wait or
  lower --limit when it was the token's own quota. The listing no longer tells
  somebody who has not set a token that GitHub is "rate limiting this token".
• The listing no longer retries an exhausted hourly quota. That backoff waits
  20, 40 and 60 seconds, so an unauthenticated caller sat through two minutes of
  silence before getting the error anyway. GitHub marks this case with
  x-ratelimit-remaining: 0; the secondary rate limit, which does recover and
  is still retried, does not.

Why the tests did not catch it

runTriageCli was never executed by the suite. Every triage test was either a
pure function or an assertion about the source text, so all 90 passed while the
command's error handling was wrong.

There is now packages/cli/test/triageRun.test.ts, which runs it against
stubbed GitHub calls. Five of its seven cases fail against the previous
code, verified by stashing the source change and re-running:

× does not count a pull request it could not read as work waiting for a maintainer
  AssertionError: expected '3 open pull request(s) read. 3 have s…'
                  to contain '2 open pull request(s) read. 2 have s…'
× stops at an exhausted quota rather than blaming every remaining pull request
  AssertionError: expected "vi.fn()" to be called 1 times, but got 4 times

Documentation

The README, getting started, and docs/triage.md all said a token was for
private repositories and higher rate limits. For this command it is required,
and they now say so, including that a token with no scopes is enough.

Verification

pnpm build && pnpm test && pnpm typecheck && pnpm lint && pnpm format:check,
all green. 461 tests, up from 453.