fix(performance): fetch GitHub commits concurrently to prevent serverless timeouts

[nyxsky404]

This PR refactors the GitHub Search API pagination in fetchContributionsForAccount. Previously, the route fetched up to 10 pages sequentially in a while loop, which could take up to 20 seconds for highly active users and frequently caused 504 Gateway Timeouts on Vercel's edge/serverless architecture. The new implementation fetches the first page to determine the total_count, and then fetches the remaining required pages (up to 10 max) concurrently using Promise.all(). This drastically reduces the total execution time while correctly handling secondary rate limit (HTTP 429/403) fallbacks. Fixes #3170.

[github-actions]

GSSoC Label Checklist 🏷️

@Priyanshu-byte-coder — please apply the appropriate labels before merging:

Difficulty (pick one):

• level:beginner — 20 pts
• level:intermediate — 35 pts
• level:advanced — 55 pts
• level:critical — 80 pts

Quality (optional):

• quality:clean — ×1.2 multiplier
• quality:exceptional — ×1.5 multiplier

Validation (required to score):

• gssoc:approved — counts for points
• gssoc:invalid / gssoc:spam / gssoc:ai-slop — does not score

Type labels (type:*) are auto-detected from files and title. Review and adjust if needed.
Points formula: (difficulty × quality_multiplier) + type_bonus

[Priyanshu-byte-coder]

Good instinct on the serverless timeout, but firing pages 2..N as fully-parallel Promise.all fans out up to ~9 concurrent GitHub Search calls on a single user token. GitHub's own guidance is explicit: "make requests for a single user serially… do not make them concurrently," and Search has a low secondary rate limit — a burst like this risks tripping a secondary-rate-limit block, which is worse than the sequential latency it replaces. Please cap concurrency to a small pool (2-3 at a time) instead of unbounded parallel, then I'll take another look. Also: rate-limited pages now silently drop their items — that's fine as partial results, just confirm that's intended.

[nyxsky404]

@Priyanshu-byte-coder

Updated:

• Capped concurrency for pages 2..N to a bounded pool of 3 at a time (matches the same pattern used in prs/route.ts's CONCURRENCY_BATCH), instead of firing all remaining pages via a single Promise.all. This keeps us within GitHub's guidance against concurrent requests on a single token while still avoiding the sequential-latency timeout.
• Confirmed: rate-limited pages intentionally return no items and the response falls back to whatever pages were already fetched, rather than failing the whole request. Added a comment in the code to make that explicit.
• Rebased onto latest main.