fix(git): parse worktree-side status renames

[Duang777]

Summary

• Treat R and C in either porcelain status column as two-path records.
• Keep the parser aligned so later untracked paths are not skipped.
• Add focused tests for worktree-side renames in both status parsers.

This is the small, independent parser fix extracted from #4112 after the request to split that PR.

Verification

• Red check: both new tests fail with the old first-column-only condition.
• cargo test --lib worktree_rename
• cargo run -- hook pre-merge --yes (4,932 passed, 1 expected skipped)

[worktrunk-bot]

Outside this diff, parse_working_tree_status in src/commands/list/collect/tasks.rs carries the same first-column-only assumption: if index_status == 'R' { has_renamed = true; }, with 'R' in neither of the matches! arms above it. A R entry therefore sets no flag at all and WorkingTreeStatus::is_dirty() comes back false, so a worktree whose only change is a worktree-side rename renders as clean in wt list:

$ mv a.txt b.txt && git add -N b.txt
$ git status --porcelain
 R a.txt -> b.txt
$ wt list --format json | jq -c '.items[0].worktree.changes'
{"staged":false,"modified":false,"untracked":false,"renamed":false,"deleted":false,"conflicted":false,...}

That one is display-only — the removal and merge gates go through WorkingTree::is_dirty, which is a non-empty check over the raw porcelain, so no safety check is reading the flags.

Happy to push the flag mapping as a commit here, or leave it for a follow-up PR — whichever you'd prefer, given the request to keep this one narrow.