fix(strategy): compare redo content in the commit index

[MuskanPaliwal]

git commit -a and path-limited commits prepare the commit in a temporary GIT_INDEX_FILE. Redo detection (inheritReplacedCommitsTrailers) read staged paths from that index but blob IDs from go-git's ordinary index, so it compared the dropped commit with content that was not being committed. It also let git's rename detection hide staged deletions. The inherited Entire-Checkpoint trailer was wrong in both directions.

Problem

After git reset HEAD~1:

• Recommitting the dropped commit's exact content with git commit -a, git commit -- <path> or git commit --amend -a loses its trailer.
• Staging that content, rewriting a file, then committing with -a or -- <path> inherits the trailer for work the commit no longer contains.
• Deleting a file the dropped commit changed, while adding a similar file, also inherits the trailer, even with a plain git add and git commit. Git reports the pair as a rename, so the deletion is never compared.

A plain git add followed by git commit was otherwise correct, because both indexes agree.

Cause

stagedBlobs (manual_commit_redo.go, added in 6170bc1) listed paths with getStagedFiles, which runs git diff --cached and so honors GIT_INDEX_FILE. It then looked up each blob in repo.Storer.Index(), which reads .git/index. During -a, path-limited and --amend -a commits, those are different indexes.

git diff --cached also detects renames, following the user's diff.renames (on by default). A rename's raw record carries only its destination path, so the source's staged deletion never reached the comparison.

The existing redo tests call PrepareCommitMsg directly, where no temporary index exists, so they could not see the difference.

Fix

getStagedChanges reads paths and full blob IDs in one git diff --cached --raw -z --no-abbrev query, through the existing parseStagedRaw (which already skips submodule gitlinks and reports rename destinations). getStagedFiles and stagedBlobs both build on it, and the second index read is removed. The query deliberately keeps the hook environment: GIT_INDEX_FILE identifies the commit Git is preparing.

stagedBlobs adds --no-renames, so a rename's source is compared as the staged deletion it is. getStagedFiles keeps reporting a rename's new path, so its squash and session-overlap callers do not change.

git-safety.md moves the hook-environment rules into their own section and adds the --no-renames rule. CLAUDE.md now also covers hook queries of the hook's own refs, which the redo path runs.

How this PR changed

This PR originally fixed the same mismatch in session linking (stagedFilesOverlapWithContent). Upstream 389e855 then made new-file linking match by name, and prepare-commit-msg stopped reading the index there, so that change no longer applies and was dropped while syncing with main. The same mismatch had meanwhile appeared in redo detection, which this PR now fixes.

I started this from the side finding in #2303 about getStagedFiles, which suggests stripping the hook environment. Doing that would read both paths and blob IDs from .git/index. They'd agree with each other and still miss what git commit -a or a path-limited commit records. This fix keeps GIT_INDEX_FILE, so the comparison reads the index Git is committing from.

Related: #2111. This does not fix its empty-tree corruption.

Tests

TestRedo_ComparesTheCommitIndex runs real git commit through Entire's hooks, with the arguments the installed hooks pass. The dropped commit edits a.txt and b.txt and deletes d.txt.

Verified RED against main:

--- FAIL: TestRedo_ComparesTheCommitIndex/all                []string(nil) does not contain "a1b2c3d4e5f6"
--- FAIL: TestRedo_ComparesTheCommitIndex/partial            []string(nil) does not contain "a1b2c3d4e5f6"
--- FAIL: TestRedo_ComparesTheCommitIndex/amend-all          []string(nil) does not contain "a1b2c3d4e5f6"
--- FAIL: TestRedo_ComparesTheCommitIndex/all-rewritten      []string{"a1b2c3d4e5f6"} should not contain "a1b2c3d4e5f6"
--- FAIL: TestRedo_ComparesTheCommitIndex/partial-rewritten  []string{"a1b2c3d4e5f6"} should not contain "a1b2c3d4e5f6"
--- FAIL: TestRedo_ComparesTheCommitIndex/renamed-deletion   []string{"a1b2c3d4e5f6"} should not contain "a1b2c3d4e5f6"

With the commit-index change alone, only renamed-deletion still fails; --no-renames fixes it. The staged case passes throughout, as a control. All seven pass with the fix. TestParseStagedRaw also asserts each path's blob ID and deletions.

Test plan

• TestRedo_ComparesTheCommitIndex (7 cases), plus the existing redo and adversarial redo tests
• mise run lint: 0 issues
• mise run check: passes except TestExternalCommand_SigintReachesPlugin, which failed once under -race load (its plugin never reached the ready state) and passes 3/3 when run alone
• Paid real-agent E2E tests not run

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[MuskanPaliwal]

The two red checks (test-core, and test, which only reports test-core's result) come from four checkpoint-preview tests that fail on main as well, not from this change:

• TestPreviewNextCheckpoint
• TestCheckpointListPending_PreviewText
• TestCheckpointListPending_PreviewJSON
• TestCheckpointListPending_PreviewEmptyArraysPresent

Their fixtures (from 6142ebe) use fixed session timestamps on 2026-10-07. session.StaleSessionThreshold is 7 days, so since about 2026-10-14 12:00 UTC those sessions load as stale and the previews come back empty. They fail the same way on an unmodified checkout of main (ffc17a1).

#2769 fixes the three TestCheckpointListPending_* tests by deriving the session times from time.Now(). TestPreviewNextCheckpoint (cmd/entire/cli/strategy/manual_commit_preview_test.go) has the same fixed date and isn't covered there yet. No redo, staged-file, or integration test failed here.