fix: correctly handle renamed files in the commit view (list + diffs)

[rubensa]

Fixes #187. Fixes #131.

Supersedes #188 — that PR fixed only the file-list parsing (#187). While
testing it I found that once renamed files finally appear in the list, opening
their diff still breaks (#131), because the two bugs share the same root cause:
renames aren't tracked through to the paths used per revision. This PR fixes
both, so I'll close #188 in favour of it.

This is two commits; they can be reviewed independently.

---

Commit 1 — parse git's compact {old => new} rename notation (#187)

When a commit renames a directory, git reports the moved files with its
compact rename notation, e.g. src/{old => new}/file.txt. The file-list
parser (git_numstat_summary_to_changes_array in
web/src/components/CommitDiff.vue, fed by git show --numstat --summary) only
understood the full-path form old => new.

For a numstat row like src/{old => new}/file.txt it did:

path = path.split(' => ')[0]?.replaceAll('{', '') || ''
// "src/{old => new}/file.txt"
//   .split(' => ')[0]   -> "src/{old"
//   .replaceAll('{','') -> "src/old"   <-- truncated at the brace; "/file.txt" is lost

So every file renamed under the same directory collapsed onto the same
key (src/old) and the entries overwrote each other in the accumulator — only
the last survived. The --summary rename branch had the same assumption, so it
couldn't reconcile either. Result: files silently missing from the commit's
file list, and a basename that also appeared as a plain add/delete pair could
show up duplicated.

Fix: a small split_rename() helper expands git's compact form
prefix/{old => new}/suffix (and the degenerate {old => new},
dir/{ => new}/f, dir/{old => }/f, and plain old => new) into the real
old/new paths, and the entries are keyed on the real old path in both the
numstat branch and the --summary rename branch.

Commit 2 — use old/new paths for renamed files in commit diffs (#131)

Once #187 makes renamed files appear in the list, clicking one opened an empty
diff (and "View File at this Revision" opened an empty editor). A renamed file's
old name exists only in the parent commit and its new name only in the
child, but the handlers used a single path for both revisions:

uris: [
  `${hash1.value}:${filepath}`,   // parent : path
  `${hash2(filepath)}:${filepath}`, // child : SAME path  <- absent here for a rename
]

So the child side resolved a path that doesn't exist in that commit and rendered
empty.

Fix: track new_path on each FileDiff, and use the old path at
hash1 and the new path at hash2 in show_diff / show_multi_diff /
view_rev, and the new path for open_file / show_file. Non-renamed
files are unaffected because new_path === path for them.

---

Verification

Built and type-checked locally against a fresh checkout:

• npm run build (vite + esbuild) — passes.
• vue-tsc --noEmit — no new errors from either change (the one remaining
  CommitDiff.vue diagnostic is pre-existing and present on the unmodified
  tree, just line-shifted).
• Parser check on a directory rename (src/old/ → src/new/): before only
  1 of 2 renamed files appeared (both collapsed onto one key); after both
  appear with correct old/new paths. The loss scales with the directory — an
  N-file rename previously collapsed all N brace entries onto a single key.
• Diff-URI check on a rename: before the child side reused the old path and
  the pane was empty; after it resolves parent:old ↔ child:new and both
  panes populate. Modified/created/deleted files produce identical URIs to
  before.

Note: npm run lint currently crashes in a fresh checkout on
src/global.d.ts (a @typescript-eslint/TS version issue, unrelated to this
change), so I couldn't run the lint gate — the type-check and build above
cover this file.

Reproduce the original bugs

git init demo && cd demo
mkdir -p src/old
printf 'a\n'    > src/old/keep.txt
printf 'a\nb\n' > src/old/edit.txt
git add -A && git commit -m init
git mv src/old src/new                 # rename the directory (both files move)
git commit -am "rename dir"

Open the rename dir commit:

• Before Files missing/duplicated in commit file list when a directory is renamed ({old => new} brace notation not parsed) #187: at least one renamed file is missing from the file list;
  with more files in the directory, several go missing and a basename can appear
  duplicated.
• Before Empty diffs when file renamed and modified #131: the renamed files that do show open an empty diff and an
  empty "View File at this Revision".
• After this PR: all renamed files are listed, and their diffs and file
  views open correctly.