[feature]: Improve GitHub API Rate Limit Handling for Large Repositories in the stargazers script

### 👀 Is there an existing feature request for this?

- [x] I have searched the existing issues

### 🔖 Enhancement description

# 🛠️ Improve GitHub API Rate Limit Handling for Large Repositories

## 🔖 Enhancement Description
Currently, the script relies on a GitHub access token, which has a rate limit of **5000 API calls per hour**. When fetching stargazers for repositories with a large number of stars, the script exceeds this limit, causing it to fail and requiring a reload after an hour.

To improve efficiency and make the script more reliable for large repositories, we need to explore and implement solutions to handle API rate limits effectively.

## 📌 Expected Behavior
- The script should be able to handle large repositories without exhausting API limits quickly.
- It should gracefully handle rate limits and avoid abrupt failures.
- Users should be able to continue fetching stargazers without waiting for an hour.

## ⚙️ Current Behavior
- The script stops working when the **5000 API call per hour** limit is exceeded.
- It forces users to wait for an hour before they can resume fetching.
- No built-in handling for rate limits or alternative approaches exists.

## 💡 Suggested Solutions
1. **Implement API Pagination and Caching**
- Optimize API calls by storing already fetched stargazers in cache/local storage.
- Fetch only new stargazers instead of repeatedly requesting the full list.

2. **Use Multiple GitHub Access Tokens**
- Support multiple GitHub tokens to distribute API requests across different credentials.
- Implement token rotation to automatically switch when one token reaches the limit.

3. **Implement GraphQL API Instead of REST**
- The GitHub GraphQL API allows fetching more data in fewer requests, reducing API usage.
- Convert API calls to GraphQL queries for better efficiency.

4. **Introduce Exponential Backoff & Retry Mechanism**
- When nearing the API limit, reduce request frequency dynamically.
- Implement a backoff strategy to retry after a delay instead of stopping completely.

5. **Use Third-Party Proxy Services or Caching Mechanisms**
- Store API responses in a temporary database (e.g., Firebase, Redis) to minimize repeated calls.
- Explore GitHub Apps authentication, which has higher rate limits compared to personal access tokens.

6. **Innovation and Custom Solutions**
- Contributors are welcome to come up with their own **creative solutions** to optimize API requests.
- Any novel approach that improves efficiency and scalability is highly encouraged!

## 🎯 Impact
- Makes the script **more robust and scalable** for repositories with a high number of stargazers.
- Ensures **continuous operation** without abrupt failures due to API rate limits.
- Improves **efficiency and reliability** by optimizing API requests.

### 🎤 Why should this be worked on?

Handling API rate limits efficiently is crucial to ensure seamless functionality for large repositories. Implementing these optimizations will:
- Prevent users from **waiting an hour** due to exceeded rate limits.
- Improve **performance** by reducing unnecessary API calls.
- Enhance **scalability**, allowing the script to support large repositories effortlessly.

### 💻 Repository

keploy

No files, tests, or entry points are named. Start by locating the stargazers script and its GitHub API request handling, then determine how pagination, caching, authentication, and rate-limit retries currently work; done means large repositories can continue fetching stargazers without abrupt rate-limit failure.

Written by the indexing model from the issue text.