[feat] Batch GitHub PR status fetching via GraphQL for faster sidebar updates #2845

Describe the feature

The current GitHub PR status fetching has several performance issues that compound in repos with many workspaces:

1. Slow refresh cycle (5 min stale threshold)
Each workspace's cached githubStatus is only refreshed from GitHub when it's >5 minutes old. After an agent creates a PR, the sidebar can take up to 5 minutes to reflect it.

2. N individual gh pr view calls
When stale workspaces are refreshed, each one makes a separate gh pr view CLI call. For a project with 20 workspaces, that's 20 sequential shell invocations.

3. Sidebar badges only populate on hover
WorkspaceListItem gates the getGitHubStatus query on hasHovered, so PR badges are empty until you hover each workspace individually. On app launch, none of the sidebar items show PR status.

4. Hover card shows "Loading PR..." even when data exists
When hovering a workspace, the hover card calls getGitHubStatus which hits the in-memory cache. But the batch fetch writes to the DB cache without populating the in-memory cache, so the hover card doesn't see it.

Proposed solution

Replace per-workspace gh pr view calls with a single GitHub GraphQL query using aliases to fetch all PR statuses across all projects:

query {
  repo1: repository(owner: "org", name: "repo1") {
    pr_0: pullRequests(first: 1, headRefName: "feat/foo") {
      nodes { number state reviewDecision statusCheckRollup { ... } ... }
    }
    pr_1: pullRequests(first: 1, headRefName: "fix/bar") { ... }
  }
  repo2: repository(owner: "org", name: "repo2") { ... }
}

This gives:

• 1 API call for all workspaces across all projects (grouped by repo, multiple repos in one query)
• 10 second polling is feasible since it's just one call (well within GitHub's 5,000 req/hr limit)
• Sidebar badges populate immediately — all WorkspaceListItem components read from the same shared React Query cache
• Hover cards show cached data instantly — populate the in-memory githubStatusResource cache from batch results so getGitHubStatus reads it without hitting gh CLI

Additional context

The gh api graphql command is already used in the codebase (e.g. comments.ts for review threads). The existing getGitHubStatus per-workspace flow can remain as a fallback, with the batch query as the primary data source.

GitHub rate limit math: 1 call every 10s = 6/min = 360/hr, well under the 5,000/hr limit even with multiple repos.