perf: fetch pr blobs by blob sha

[hashiiiii]

Summary

Fetches PR file contents by blob SHA (git/blobs/{sha}) instead of path+ref (contents/{path}?ref=), eliminating the erratic multi-second server-side stalls of the contents API that pushed semantic-diff first paint to ~10s on PR files pages.

Motivation

Closes #110. Measured against the same endpoints: contents-by-path TTFB ranges 0.25–8.0s independent of file size (five of six identical requests at 0.25–0.6s, one at 4.9s), while blobs-by-SHA stays at 0.27–0.46s across all runs. With ~36 contents calls behind a 6-slot queue, a handful of stalled calls gated every file's render.

Changes

• PrFile now carries the blob sha from the files API (head side; base side for removed files)
• GithubClient.getBlobRaw fetches raw bytes by blob SHA; listBlobShas maps path → blob SHA from one recursive tree call
• loadContext resolves base-side SHAs via a single git/trees/{mergeBase}?recursive=1 call, in parallel with the guid index; rate limits propagate, other failures degrade to the contents fallback
• fetchBlob accepts an optional blob SHA (cache key folds with prefetch); a 404 on the SHA falls back to path+ref
• fetchPair, buildGuidIndex, and base-side mergeSources fetches all ride the SHA path; head-side source prefabs (not PR files) keep the contents fallback
• Note: the base tree map is held per PR context (60s TTL); on a 100k-file repo that is one transient Map in SW memory

Testing

• pnpm test — 184 passed (12 new: blob-SHA pair/meta fetching, renamed/removed sides, truncated-tree and 404 fallbacks, rate-limit propagation)
• pnpm typecheck, pnpm lint, pnpm build — clean
• pnpm e2e — 10 passed (extension loaded in Chromium)
• New tests were written first and observed failing (getBlobRaw is not a function, contents API still touched) before implementation