Work diff canvas ignores copy headers when the user's Git config sets diff.renames=copies #286

Expected and actual behavior / 实际现象与期望

With diff.renames=copies in the user's Git config, git diff reports a new file that is a copy of a changed file with copy from / copy to extended headers. parse_unified_diff handles rename from / rename to but ignores the copy headers:

• The copy is shown as modified rather than as a copied file.
• An exact copy has no --- / +++ lines, so its path comes only from the diff --git header. If the source and copy paths contain spaces and differ, that header cannot be split, so the canvas shows a phantom entry, and the real path is appended again as a second hunk-less entry from changed_files.

Expected: one copied entry per copy, with oldPath set to the source and path / newPath set to the copy, as for renames.

Steps to reproduce / 复现步骤

git config diff.renames copies
printf 'one\ntwo\n' > 'my src.txt' && git add . && git commit -m base

An attempt copies my src.txt to my dup.txt, appends a line to my src.txt, and commits. The committed attempt patch starts with

diff --git a/my src.txt b/my dup.txt
similarity index 100%
copy from my src.txt
copy to my dup.txt
diff --git a/my src.txt b/my src.txt
...

Actual canvas entries: src.txt (oldPath my, modified), my src.txt (modified), my dup.txt (modified, no hunks).
Expected: my dup.txt (copied from my src.txt), my src.txt (modified).

Relevant environment / 使用环境

Platform-independent; current main (f86c72a). Reproduced with Git 2.43 and 2.54.

Related issues or fixes / 相关问题或修复

#280 / #282 handled spaced paths without marker lines; renames already recover from rename from / rename to. The copy-header case was noted as a separate follow-up in the #282 review.