Split capped PR velocity days by repository

[mahangu]

Summary

• add a progressive fallback for pr_velocity queries that still exceed GitHub GraphQL Search's 1,000-result node cap after day slicing
• split capped windows by repository and, when needed, by created-date ranges
• keep split count reconciliation fail-fast so incomplete child windows are not accepted silently
• cover repo listing pagination, capped window fanout, created-date bisection, and reconciliation failures

Rationale

Day slicing alone is not always selective enough for high-volume repositories or organizations. A direct day-to-created-date fallback is smaller, but it can still hit the cap when many PRs share the same created and closed day. The repository step keeps leaf queries smaller while the reconciliation checks preserve fail-fast behavior.

Testing

• poetry run pytest tap_github_search/tests

[mahangu]

Updated the PR description with the public rationale: day slicing can still exceed GitHub GraphQL Search's 1,000-result node cap, so the repo split keeps leaf queries smaller while reconciliation keeps incomplete splits fail-fast. Also trimmed duplicate created-date split test setup.