Dedupe and cache `getReviewThreads` on PR load

[jennings]

Problem

getReviewThreads is called twice on every PR navigation, with no caching or in-flight dedupe:

• src/browser/components/pr-review.tsx:229 — fired from PRReviewContent on mount
• src/browser/contexts/pr-review/index.tsx:2863 — fired again from loadPRData

The function itself (src/browser/contexts/github.tsx:2699) calls batcher.query directly with no cache layer. Result: two independent GraphQL round-trips for identical data on every PR open.

Acceptance criterion

getReviewThreads is called at most once per PR load. The second consumer reads from cache (or a shared context value) rather than firing an independent GraphQL query.

Implementation plan

Route getReviewThreads through RequestCache (src/browser/contexts/github.tsx:206):

• RequestCache is the right tool here — it has both a TTL cache and a pending map for in-flight request dedupe, which is what actually solves the duplicate-fetch problem when two callers race on mount.
• Not persistent-cache.ts: review threads are mutable (new comments, resolved/unresolved state changes frequently), and persistent-cache.ts is keyed by content-addressable (owner, repo, pr, sha) for immutable data.
• Use a short TTL consistent with other mutable PR data already going through RequestCache.

Notes

• See also Drop the standalone getReviewThreads fetch in PRReviewContent #99 — that ticket removes one of the two call sites structurally. The two fixes are complementary: this one (cache + dedupe) is the safety net across all callers; the structural fix prevents the duplicate from existing in the first place. Either can ship first.
• Impact: HIGH — runs on a hot path (every PR navigation), removes one full GraphQL round-trip per PR load.