fix(ci): follow GitLab x-next-page past filtered short pages - #2912

What

GitLab inline reviews stop posting the same comment again on every pipeline. fallow ci post-review and ci reconcile-review now read every page of an MR's discussions, so they find the threads Fallow already opened. The sticky summary lookup (ci post-pr-comment) gets the same fix, so it no longer risks creating a second summary comment.

• gitlab_get_page returns the page together with GitLab's x-next-page header, read as "another page follows".
• gitlab_has_more_pages trusts that header. The old rule (a page shorter than 100 is the last one) applies only when the header is missing.
• An empty page no longer ends the discussions lookup while x-next-page names another page.
• Every GitLab GET goes through the one paged reader, so the token-leak source guard still sees three PRIVATE-TOKEN paths. with_retryable_status is now a thin wrapper over a generic with_retryable_response, so the reader gets the final response's headers without a second retry loop.

Why

GitLab removes discussions and notes the token may not see after it cuts a page. So a page can hold 99 items while more pages follow. Fallow treated any short page as the last one. It never reached its own threads on later pages, planned every finding as new, and resolved nothing.

Measured on a real MR with 760 discussions, as seen by the project bot that runs the review job:

Fallow stopped after page 1, so every pipeline posted all current findings again; one finding had 18 copies, 7 still open. A user who can see the hidden discussion gets 100 items on page 1, which is why the bug didn't show when checked from a personal account.

Test plan

• cargo test -p fallow-cli --test integration reconcile_review: 50 passed. The three new tests fail on main:
  • gitlab_post_review_follows_next_page_past_a_filtered_short_page: main posts the comment again
  • gitlab_post_review_follows_next_page_past_a_fully_filtered_page
  • gitlab_sticky_comment_lookup_follows_next_page_past_a_filtered_short_page: main plans create instead of update
• cargo test -p fallow-cli --lib: 2996 passed, including the new gitlab_has_more_pages_trusts_next_page_header_over_page_size and the api::tests source guards
• cargo clippy -p fallow-cli --all-targets -- -D warnings
• cargo fmt --all -- --check
• npm run verify:fast
• Real-data replay: that MR's 758 discussions plus the job's own review envelope, served with one discussion hidden from page 1 and real x-next-page headers. main: 7 posted, 0 stale, the same as the CI job. This branch: 7 skipped, 20 stale seen.
• Independent Rust and CI-integration reviews: the one gap they found (a fully filtered page) is fixed above
• Not yet run against gitlab.com; that needs a release

The two GitHub list loops still use the page-size rule. GitHub paginates with Link headers, and there's no evidence that it drops items after slicing, so they are unchanged. The GitLab sticky note lookup still stops silently at 100 pages, as before.