fix(forge): support PRs with over 300 changed files

[pbjorklund]

tuicr cannot open pull requests with more than 300 changed files. GitHub stops serving the combined diff at that point, and patches large enough to hit the limit also made file and commit navigation slow.

This PR removes that limit and keeps large reviews usable.

Approach

Normal PRs still use gh pr diff. The fallback runs only for GitHub's specific 300-file error.

When tuicr is running inside a checkout for the same repository, it checks that the current branch name and HEAD match the PR metadata exactly. If the base commit is also available, Git can build the merge-base diff from the local object database. The command compares two commits, so dirty files, staged changes, and untracked files are not included.

If any check fails, tuicr creates a blobless bare repository under the system temporary directory. It can borrow objects from the matching local repository, including from a linked worktree's common Git directory, then fetches the missing base and PR objects into the temporary repository. The temporary repository is deleted when the diff is ready.

External diff, textconv, and replace objects are disabled for locally generated diffs. Other gh pr diff errors are returned as before.

Other approaches tried and ruled out

• GitHub's pull-request files API: This was the first fallback implementation. It requires rebuilding unified patches from per-file responses, omits some patch data, and has its own 3,000-file ceiling.
• Always create a temporary clone: This is correct and remains the final fallback, but it repeats network and disk work when the exact commits are already present. On the large test PR it made startup roughly twice as slow.
• Fetch into the user's checkout: This avoids another repository but changes local Git state during a read-only review. It also needs cleanup and recovery if the process stops partway through.
• Create a linked worktree under /tmp: A worktree is useful when files must be edited or tested. This path only needs a commit-to-commit diff. Adding a worktree still writes administrative state into the user's repository, can leave stale entries after interruption, and does not solve missing objects without a fetch.
• Trust any matching checkout: Repository name or branch name alone is not enough. Forks, shallow clones, stale branches, detached heads, and advanced base branches can otherwise produce the wrong diff.

The current hybrid keeps the common checked-out-PR case local and read-only. Cases that cannot prove they have the exact commits use the isolated fallback instead.

Large-review rendering keeps only visible rows plus overscan. File and hunk positions are cached, and parsing, syntax highlighting, range saves, and cleanup no longer block the input loop. This follows the background-work direction from agavra#288 without exposing partially built diffs to the UI.

The real test case changes 592 files and produces a 408,004-line patch. With the PR branch checked out, startup app initialization dropped from about 16 seconds to 8.4 seconds and did not run gh repo clone. File navigation takes 10-11 ms, cached commit-range changes take about 6 ms, and the 400,000-line release benchmark averages 165 microseconds per navigation frame.

The fallback tests cover exact and stale PR heads, dirty and staged state isolation, detached heads, shallow clones missing the base, advanced base branches, linked worktrees, local object borrowing, no-checkout clones, merge-base behavior, external diff and textconv suppression, replace objects, cleanup, and the 301-file end-to-end case. Local formatting, Clippy, 1,106 tests, the release performance benchmark, CodeGraph sync, and the security review pass.

[pbjorklund]

Superseded by agavra#475.