fix(inngest): clear sync cursor in catch block to prevent stale cursor deadlock on prBackfill pagination errors

[yush-1018]

####Overview
Fixes an issue in prBackfill (src/inngest/functions/pr-backfill.ts) where a GitHub API error during pagination (e.g. 502 Bad Gateway or network timeout on Page 5) caused catch (e) to log the error and return without calling clearSyncCursor. This left repo_sync_cursors stuck at the last successful page (e.g. Page 4), trapping all future backfill runs in an infinite deadlock on Page 5.

####Changes Made

• Error Cursor Cleanup: Added await clearSyncCursor(installationId, repoFullName, 'pull_requests'); inside the catch (e) block of backfillSingleRepo() in src/inngest/functions/pr-backfill.ts so failed cursors are cleaned up and future backfill runs start fresh.
• Unit Tests: Added test case in src/inngest/functions/pr-backfill.test.ts verifying clearSyncCursor is invoked when pulls.list throws.

####Quality Control

• Lint: ESLint passed with 0 errors and 0 warnings.
• Unit Tests: All 8 unit tests in pr-backfill.test.ts pass cleanly.

#850

[vercel]

@yush-1018 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.

[jakharmonika364]

Clearing the cursor on any pulls.list error works for transient failures (502s, timeouts), but if the throw is actually coming from classifyPrAsAi on a specific PR's content (it's unguarded, unlike listReviews right below it which has its own try/catch), restarting from page 1 will just walk back to the same PR and fail the same way - cursor keeps getting cleared, deadlock isn't actually broken, just more expensive per attempt. Do we know which case #850 was actually hitting? If it's classification-triggered, wrapping classifyPrAsAi in its own try/catch (log + continue, same pattern as reviews) would be the more targeted fix.

[jakharmonika364]

lgtm