bug(inngest): stale sync cursor in prBackfill causes pagination deadlock on GitHub API errors

[yush-1018]

What happened?

Summary

In prBackfill (src/inngest/functions/pr-backfill.ts), if octokit.paginate.iterator throws an exception midway through processing pages, the try-catch block catches the error and returns cleanly without clearing or resetting the repo_sync_cursors table row. Subsequent backfill runs read the stale cursor, forcing the job to re-start at the failing page in an infinite loop.

Root Cause

In src/inngest/functions/pr-backfill.ts (lines 258–261):

    // Finished processing all pages
    await clearSyncCursor(installationId, repoFullName, 'pull_requests');
  } catch (e) {
    errors.push(`pulls.list: ${(e as Error).message}`);
  }

### Steps to Reproduce

1. Trigger a PR backfill on a repo with >500 PRs.
2. Simulate a GitHub API 502/503 or network drop while fetching Page 5.
3. Observe that `setSyncCursor` saved Page 4 before Page 5 failed.
4. `catch (e)` logs the error into `errors[]` and returns without calling `clearSyncCursor`.
5. Trigger `prBackfill` again.
6. Observe that `startingPage` reads `lastProcessedPage = 4`, forcing `currentPage = 5` repeatedly.

### Expected Behavior

- Either re-throw the error so Inngest retries the step naturally, OR
- Clear/reset the cursor in a finally block or on fatal errors so future backfills can start fresh.

### Where does this occur?

Contributor Dashboard