perf: fetch merged PRs via GraphQL (different rate-limit bucket)

[costajohnt]

Summary

Closes the rate-limit risk introduced by #1's pagination fix.

The merged-PR pagination was hitting GitHub's 30/min REST search bucket: up to 10 search calls per cold-start × 4 widget endpoints = 40 search calls in a cold-start cluster. Each cold-start storm reliably tripped 429s in production.

This switches the merged-PR fetch to GraphQL search, which counts against the 5000-points-per-hour GraphQL bucket instead of the search bucket. At ~1 point per page, 4 widgets × 10 pages = 40 points/storm — plenty of headroom.

Bonus: `repository.stargazerCount` comes inline in the GraphQL response, so the card/recent/top-repos transforms no longer need separate `getStarsForRepos` roundtrips. Eliminates ~36 extra core-API calls on cold start.

Diffs

• github-data.ts: `paginateMergedPRsGraphQL` replaces `paginateSearch`. Open/closed-unmerged counts still use REST search (1 call each, within budget).
• ContributionData: adds `repoStars: Record<string, number>`, populated inline by the GraphQL fetch.
• api/card, api/recent, api/top-repos: filter by `data.repoStars` instead of round-tripping `getStarsForRepos`.

Test plan

• `pnpm test` — 114/114 passing (test mocks rewritten to graphql shape, helper `gqlPage` keeps fixtures readable)
• `pnpm run typecheck` — clean
• After deploy, hit all 4 endpoints with `cache=no` simultaneously — should NOT trigger 429s anymore (was the failure mode that started this PR)
• Verify card still serves 114 / 36 with the right top repos