fix: route sync PRs/calendar through Octokit install client

[ionfwsrijan]

Fix: Route Sync PRs/Calendar Through the Octokit Install Client (#859)

Problem

The GitHub sync code called the REST Search API and GraphQL with a raw installation token via global.fetch, bypassing the Octokit client (src/lib/github/app.ts) that centralizes token acquisition, rate-budget tracking, and secondary rate-limit backoff. The user-triggered sync action and the background github-stats-sync Inngest job also carried two divergent, duplicated PR-backfill implementations that could drift.

Changes

• src/app/actions/github-sync-helpers.ts: fetchMergedCount, fetchContributionCalendar, and fetchContributionStreak now take an Octokit and use octokit.search.issuesAndPullRequests / octokit.graphql instead of raw fetch. Added a single shared fetchAndBackfillPRs (up to 100 PRs, upsert into pull_requests) that fails closed — no install id or a GitHub API error throws rather than silently degrading the sync.
• src/app/actions/github-sync.ts: now re-exports the backfill + types from the helpers, so the action and the Inngest job share one implementation.
• src/inngest/functions/github-stats-sync.ts and src/inngest/functions/audit-run.ts: same Octokit wiring.
• src/lib/github/app.ts: getInstallOctokit is the single entry point (tokens, rate-budget recording, backoff).
• Tests rewritten to mock getInstallOctokit instead of global.fetch, with new expectations for fail-closed install id and propagated API failures.

Impact

All GitHub traffic flows through the Octokit install client with centralized rate handling, and sync behavior can no longer diverge between the action and the background job.

Closes #859

[vercel]

@ionfwsrijan is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel.

A member of the Team first needs to authorize it.

[ionfwsrijan]

@Soumya-codr @codersogs-code Please review this

[jakharmonika364]

Traced the fail-closed change through both call sites - syncGitHubStats's existing try/catch absorbs the new throw cleanly, and adding fetchAndBackfillPRs to the Inngest job matches what #859 asked for, so no unhandled-exception concerns.

One gap: the new retry/backoff logic in getInstallOctokit's request hook has no test coverage - could you add a case for a 429 succeeding on retry, and one for MAX_ATTEMPTS exhaustion? Also the throw new Error('Exhausted retry attempts...') after the loop is dead code since every loop path already returns or throws.

[ionfwsrijan]

@jakharmonika364 I've made the changes