capture scenario where git hooks are overwritten during a running agent prompt

[Soph]

This is in context of: #784

It validates the assumption around hooks being overwritten but not the exact scenario described there. In the issue the next prompt fails too but this test shows our restore git hook logic works and recovers for the next prompt.

---

Note

Low Risk
Low risk: adds an integration test only, but it touches git hook state on disk and could be flaky if the test harness or hook detection changes.

Overview
Adds a new integration test (hook_overwrite_test.go) that reproduces the issue-784 scenario where third-party tools overwrite managed git hooks mid prompt, causing an intermediate commit to miss the checkpoint trailer.

The test then starts a second prompt to assert EnsureSetup reinstalls hooks (including creating .pre-entire backups for chaining) and that subsequent commits again include a checkpoint trailer with a new checkpoint ID.

^{Written by Cursor Bugbot for commit 5b4aa6d. Configure here.}

[Copilot]

Pull request overview

Adds an integration test to exercise recovery when Entire-managed git hooks are overwritten mid-turn, validating that a subsequent prompt’s setup re-installs hooks so later commits regain the Entire-Checkpoint trailer.

Changes:

• Added a new integration test that simulates hooks being overwritten mid-turn and verifies trailer presence/absence across commits.
• Verifies EnsureSetup re-installs hooks and creates .pre-entire backups when third-party hook content is detected.

[Copilot]

This test is described as “Prompt 2 / next prompt recovers” for the scenario in #784, but it creates a new session ID (sess2 := env.NewSession()). In the real flow, subsequent prompts are additional turns within the same running session, so using a new session can mask bugs that only appear when the same session continues across turns. Consider reusing sess.ID for prompt 2 (and rewriting/updating the same transcript path) so the test actually exercises recovery within a single session.

Suggested change

	sess2 := env.NewSession()
	env.WriteFile("fileC.go", "package main\n\nfunc C() {}\n")
	sess2.CreateTranscript("Create file C", []FileChange{
	{Path: "fileC.go", Content: "package main\n\nfunc C() {}\n"},
	})
	err = env.SimulateUserPromptSubmitWithPromptAndTranscriptPath(
	sess2.ID, "Create file C", sess2.TranscriptPath)
	env.WriteFile("fileC.go", "package main\n\nfunc C() {}\n")
	sess.CreateTranscript("Create file C", []FileChange{
	{Path: "fileC.go", Content: "package main\n\nfunc C() {}\n"},
	})
	err = env.SimulateUserPromptSubmitWithPromptAndTranscriptPath(
	sess.ID, "Create file C", sess.TranscriptPath)

[Copilot]

The comment says “git runs the husky hook script”, but the code path here (env.GitCommit) uses go-git and intentionally does not execute any hook scripts. Tweaking the comment to reflect that this is simulating a commit where entire is not invoked (because hooks are overwritten / bypassed) would make the test’s intent clearer and avoid confusion for future readers.

Suggested change

	// This simulates what happens in the real world: git runs the husky hook script,
	// which doesn't call `entire`, so no trailer is added.
	// This simulates the real-world situation after husky/lefthook has overwritten
	// our hooks: a commit is made where git would run a third-party hook that does
	// not call `entire`, so from Entire's perspective no hooks run and no trailer
	// is added.