[Feature] Optimize get -q with phased pagination concurrency across providers

[mbe24]

Problem

99problems get -q currently paginates search results sequentially across providers. For multi-page queries, end-to-end runtime becomes dominated by page-by-page network waiting.

Design

Implement phased pagination optimization for -q:

1. parallelize safe page-number/offset endpoints with bounded in-flight requests,
2. keep deterministic output ordering,
3. handle token/cursor-based endpoints conservatively (pipeline or sequential fallback),
4. preserve existing error categories and behavior.

Scope

• Add internal bounded pagination scheduler for query/search paths.
• Roll out phased search pagination optimization across providers.
• Preserve deterministic emit order by page/index.
• Keep existing provider auth/rate-limit/error semantics.
• Add tests and trace-level diagnostics for pagination scheduling behavior.

Boundary

• No new CLI flags/config keys in this phase.
• No by-id hydration/comment-pagination changes in this issue.
• No aggressive fan-out for token/cursor-constrained endpoints.

Acceptance Criteria

• Multi-page -q runs show lower wall-clock time in representative scenarios.
• Emitted conversation ordering stays stable and deterministic.
• Search result completeness remains unchanged versus baseline.
• Error categories/exit codes remain consistent with current behavior.
• Tests and pedantic clippy checks pass.

Context

Recent provider hydration parallelization delivered measurable improvements. Query pagination is the next latency bottleneck for larger searches and is a natural follow-up optimization area.

• Tokio async patterns: https://tokio.rs/tokio/tutorial
• GitHub REST pagination: https://docs.github.com/en/rest/using-the-rest-api/using-pagination-in-the-rest-api
• GitLab REST pagination: https://docs.gitlab.com/ee/api/rest/#pagination
• Jira REST pagination: https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#pagination