fix(repo): paginate user repositories in repo explorer

[desireddymohithreddy0925]

Summary

This PR implements server-side pagination for the Repo Explorer. It cleanly separates the pagination functionality from the unrelated milestone/goal-category changes that caused conflicts in previous PR attempts, ensuring the UI remains fast for users with large numbers of repositories.

Closes #3136

---

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that changes existing behavior)
• 📝 Documentation update
• ♻️ Refactor / code cleanup (no functional change)
• ⚡ Performance improvement
• 🔒 Security fix
• 🧪 Tests only

---

What Changed

• src/lib/github.ts: Introduced a new fetchUserReposPaginated function and PaginatedReposResult interface to selectively fetch a specific page of repositories and extract the hasNextPage boolean from GitHub's Link header. This avoids altering the original fetchUserRepos return signature, preserving compatibility across other endpoints.
• src/app/api/metrics/repo-explorer/route.ts: Updated the endpoint to extract page and per_page query parameters. Replaced the heavy, multi-page data fetch with fetchUserReposPaginated, injecting the parameters into the cache key to accurately serve paginated chunks. The endpoint now returns { repos, hasNextPage }.
• test/github.test.ts: Added validation for the new PaginatedReposResult interface.

---

How to Test

1. Navigate to the Repo Explorer section of the dashboard.
2. Verify that only the initial subset of repositories loads on the first request (improving TTFB).
3. Attempt to fetch subsequent pages (e.g. by appending ?page=2 to the API request or utilizing the UI's pagination control).
4. Check that hasNextPage accurately reflects the presence of remaining repositories.

Expected result: The Repo Explorer should load instantly rather than waiting for up to 10 sequential API calls, and cleanly transition between pages without duplicate renders or missing commits.

---

Checklist

• Linked the related issue above
• Self-reviewed my own diff
• No unnecessary console.log, debug code, or commented-out blocks
• npm run lint passes locally
• No TypeScript errors (npm run type-check)
• Added or updated tests where applicable
• Updated documentation / comments if behavior changed

---

Accessibility (UI changes only)

• Keyboard navigation works correctly
• Color contrast meets WCAG AA standard
• ARIA labels / roles added where needed
• Tested on mobile / responsive layout

---

Additional Context

This is a focused, rebased follow-up to the previously cluttered PRs (#2903 and #3135) to implement the required API modifications securely and smoothly, ensuring a completely green build without conflicts.

[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