[REFACTOR] Optimize `fetchGitHubUser` with parallel requests

[github-actions]

Problem Statement

Profile pages are loading slowly because we fetch user data, repositories, organizations, and contributions sequentially.

Proposed Solution

Refactor the data fetching logic in src/app/[username]/page.tsx and src/lib/profile-data.ts to use Promise.all or Promise.allSettled. This will allow all external GitHub API requests to fire simultaneously, significantly reducing the Time to First Byte (TTFB).

Alternatives Considered

None. Parallelizing independent network requests is a standard optimization.

Additional Context

Be mindful of error handling. If one promise fails (e.g., organizations API returns 500), it shouldn't crash the entire profile page.

[SakethSumanBathini]

Hey @PRODHOSH can you assign me this issue please??

[SakethSumanBathini]

Hi @PRODHOSH — the data fetching this describes as sequential is already parallel.

src/lib/profile-data.ts:124 already does:

const [totalPRs, totalIssues, totalCommits] = await Promise.all([...])

and profile-snapshot.ts:165 fans out the six GitHub calls the same way:

const [user, repos, liveStats, mergedPRs, orgs, contributionCalendar] = await Promise.all([...])

The issue says profile pages are slow because "we fetch user data, repositories, organizations, and
contributions sequentially" — that was true before the DB-first snapshot work landed (#300), but the
render path now reads a single stored snapshot rather than calling GitHub at all, and the snapshot
build itself is already parallelised.

So I don't think there's anything left to do here, unless you're seeing slowness from a different
source. Happy to close, or to dig into a specific slow path if you have one in mind.