Trace: a rename inside an amend or a squash loses the AI line attribution #3686

A rename inside an amend or a squash of a session commit loses the AI line attribution. All the lines of the renamed file count as human.

Spec issue-3639 R-007 says: "Attribution MUST survive a file rename, amend, rebase, squash, and cherry-pick in the same clone. The CLI MUST match lines by content."

Steps to reproduce

1. On a feature branch, an agent session writes greeting.txt with three lines, commits it, and pushes.
2. A human runs git mv greeting.txt hello.txt, then git commit --amend --no-edit, then git push --force.

Expected

The stored session evidence lists the amended commit, and hello.txt has 3 AI lines and 0 human lines.

Actual

The evidence lists the amended commit, but hello.txt has 0 AI lines and 3 human lines.

Cause

The amended commit has no parent that holds greeting.txt, so git sees no rename: the commit creates hello.txt. The ledger of the session holds the line fingerprints under greeting.txt only. The push matches the lines of a file against the ledger of the same path and of the old paths of a rename, so no line of hello.txt matches. A squash that folds a rename into the session commit has the same result.

A rename in a separate commit keeps the AI lines, and an amend with no rename keeps them too.

Evidence

The end-to-end suite found this (spec issue-3635). The first version of the Renames and rewrites check in #3685 used this flow. #3685 documents the gap in the Trace README and tests the amend and the rename separately.