Fix: Unbounded concurrent API requests in explore() causes Secondary Rate Limit (Abuse) bans

### Bug Description
In `src/context/AppContext.jsx`, when a user explores an organization with a Personal Access Token (PAT) connected, the application attempts to fetch the contributors for **all** repositories simultaneously without batching or concurrency limits.

If a user explores a large organization (e.g., one with 200+ repositories), the `explore()` function fires hundreds of concurrent requests to the `/contributors` endpoint via `Promise.allSettled(top.map(...))`.

This triggers GitHub's Secondary Rate Limits (abuse mechanisms), resulting in immediate `403 Forbidden` errors and temporarily banning the user's PAT/IP address. Additionally, queuing this many simultaneous requests can freeze browser networking.

### Steps to Reproduce
1. Add a Personal Access Token in Settings.
2. Search for a very large organization (e.g., `google`, `facebook`, or `microsoft`).
3. Open the Network tab in DevTools.
4. Notice that hundreds of `/contributors` requests are dispatched at the exact same time, eventually failing with `403` abuse blocks.

### Expected Behavior
The `explore()` function should fetch contributors in small, manageable batches (e.g., 5 at a time) to respect GitHub's concurrency guidelines, similar to how the `runAudit()` function already handles issue fetching.

### Proposed Fix
Replace the unbounded `.map` block in `explore()` (around line 112) with a batching loop:

```javascript
// Process in safe batches of 5 to prevent abuse bans
for (let i = 0; i < top.length; i += 5) {
const batch = top.slice(i, i + 5);
await Promise.allSettled(batch.map(async repo => {
contribsPerRepo[`${org.login}/${repo.name}`] = await fetchContributors(org.login, repo.name, pat);
}));
}
```

I would love to open a PR to implement this fix!

Start in src/context/AppContext.jsx at explore(), around the contributor-fetching block, and compare it with runAudit()'s existing issue-fetching concurrency handling. Done means contributor requests are processed in small batches of five instead of all at once, while settled requests continue to be handled; verify the request pattern with a large organization in the browser Network tab.

Written by the indexing model from the issue text.