Lightweight sidebar for browsing GitHub PRs and issues (via gh CLI)

[serenNan]

What are you proposing?

A dockable sidebar panel that lists the current repo's GitHub pull requests and issues, grouped (review-requested / assigned to me / created by me / all open), with two actions per row: open in browser, and one-click gh pr checkout.

Why this is different from #37739

#37739 proposed a full PR review experience — OAuth flow, a native GitHub API client, PR detail view, comment threads, and a create-PR modal (~4,500 LOC across two new crates). It was closed due to maintainer bandwidth.

This proposal is intentionally much smaller in scope and implementation:

• No OAuth, no HTTP client, no GitHub API types. The panel shells out to the gh CLI (gh pr list --json ..., gh issue list --json ..., gh pr checkout <n>) and parses the JSON output. Auth/token handling stays entirely gh's problem, not Zed's.
• No diff/comment UI. Just list + checkout + open-in-browser. Actual review still happens in the browser, or locally via gh pr checkout + Zed's existing diff view.
• Roughly ~1,200 LOC in a single new crate (github_panel), following the same shape as git_panel / project_panel.

Why

• I already run gh pr list / gh issue list from the terminal, but it's a context switch every time. A low-friction "glance at status" panel inside the workspace removes that switch without trying to replace the browser review experience.
• Add PR-style review comments in Git Diff UI that feed into the active agent thread #59157 (open, +46 reactions) wants PR-style review comments fed into agent threads — a different and larger scope, but it signals real interest in surfacing GitHub state inside Zed generally.

Prior art

I've prototyped this already (working panel, tests passing, gh CLI backend behind a small trait so it could later be swapped for a native API client if that's ever wanted). Wanted to check direction with maintainers first, given how #37739 played out, before opening a PR.

Open question for maintainers

Is shelling out to the gh CLI an acceptable dependency shape for this, or would a minimal REST client (with a PAT, no OAuth) be preferred? I picked gh specifically to avoid writing any auth code, at the cost of requiring the CLI to be installed.