Investigate repo star verification scalability for large repositories

[BugliL]

Problem

The current repo_star verification flow checks whether a user starred a repository by fetching all stargazers for that repository and scanning the full result set for the target username.

This works for our current scale, but it can become a performance bottleneck for repositories with a large number of stars because verification cost grows with repository popularity.

Context

This came up during review on PR #32:
#32 (comment)

Relevant implementation: app/src/app/api/webhook/github/route.ts (repo_star branch).

Why this matters

• Verification latency may become high for popular repositories
• Repeated full pagination can increase GitHub API usage
• This path could become a bottleneck as GitHub-based challenges expand

Proposed follow-up

Investigate a more scalable strategy for repo_star verification, such as:

• limiting or short-circuiting the current scan where possible
• introducing caching for recent verification checks
• evaluating whether a different GitHub API approach can avoid enumerating all stargazers
• documenting acceptable scale limits if the current approach remains