pr_review.py: reviewThreads(first:100) has no pagination, so unresolved counts can undercount

[ptr727]

What

`Q_FULL` in `scripts/pr_review.py` reads `reviewThreads(first:100)` with no
`pageInfo`/`hasNextPage` tracking, unlike the `reviews`/`comments` connections
in the same query, which both carry a `hasPreviousPage` guard (`window_blind`).
A pull request with more than 100 review threads silently truncates: threads
past the first page are invisible to both the `threads=`/`unresolved=` count
and to the thread listing, with no signal that anything was cut.

Why it matters more since PR #969

`unresolved` used to count only Copilot's own threads. It now counts any of
`KNOWN_REVIEWERS` (Copilot, CodeRabbit, qodo), so a pull request with active
findings from more than one review bot fills the same fixed 100-thread window
faster than before, making the truncation more likely to actually bite.

Suggested fix

Paginate `reviewThreads` the way `Q_THREADS` already does for the reply path
(`scripts/pr_review.py`, the cursor-based query used by `reply`/`unresolved_threads`),
and/or add a truncation guard analogous to `window_blind` for `reviews`/`comments`,
so a truncated read is reported rather than silently undercounted.

Where this was raised

Qodo finding on PR #970 (the develop -> main promotion PR that included #969):
"Unresolved threads remain truncated". Deferred rather than fixed inline since
it predates #969 (Copilot-only counting could already undercount on a
pull request with >100 threads) and is a distinct, standalone scope from that
PR's Copilot-quota-detection focus.

[ptr727]

Fixed in #986, promoted to main in #991, shipped in 2.0.467. Q_FULL's reviewThreads(first:100) now tracks hasNextPage, and threads=/unresolved= print a trailing + with a THREADS TRUNCATED block when a pull request carries more than 100 review threads, rather than undercounting silently.