Open one file at a time on the commit page

Why

The commit view rendered every patch a commit contained. A broad commit (a dependency bump, a rename sweep, a generated file) turned one page load into every blob it touched, which is what made the page slow.

What

A commit now opens the same tree-and-pane layout as a change request’s Files tab: the changed-file tree on the left, one file’s diff on the right.

• The tree is built from git show --name-status (ShowNameStatus), so the cost of listing a commit does not grow with the size of its diff. The listing is read NUL-separated, so paths with spaces, tabs or non-ASCII bytes survive.
• Only the selected file’s patch is read (ShowPatchPath). A rename names both of its paths, otherwise git reports the destination as a new file.
• /r/{name}/commit/{sha}/{path} deep-links a file; a tree click swaps only #review-main over HTMX, and a path the commit did not touch is a 404.
• The 512 KiB cap still applies, now per file, and a cut patch is labelled.
• The file tree is one widget for three surfaces now, so treeView gained a Commit field and its href/target/status rules became methods (Branch, Diff, Href) instead of the old treeHref function.
• The pane’s header is one row: file name left, line counts right. The separate “1 file changed” summary line is dropped when a single file fills the pane; the total line stays for the multi-file diff a compare renders.

Docs: docs/ui-plan.md describes the commit page and the shared tree.

Tests

• server/commit_test.go (new): one patch on the page, deep links, rename shown as old → new, fragment without the shell, unknown path 404, per-file cap, and the merged name/counts header row.
• core/git/commit_test.go (new): name-status agrees with the patches, one path is not enough for a rename, root commits list additions.
• gofmt, go vet, and vole workflow run verify (format, vet, build, govulncheck, packages, markdown links, go test -race ./...) all pass.