fix: repair stale checkpoints and flag worktree setup gaps

[MuskanPaliwal]

This PR is stacked on #2404. It should target krk/doctor-shrink-checkpoint-metadata while that PR is open, then be retargeted to main after #2404 lands.

Problem

#2404 prevents new oversized prompt_attributions metadata and adds an explicit doctor repair. Two cases remain.

A stale clone can still contain the original oversized history plus newer local checkpoints after another clone repairs the remote. Its next push may reject the repaired history as unrelated or replay the old commits and reintroduce the oversized blobs.

Commit hashes cannot identify the shared boundary reliably because rewriting metadata and signing commits both change commit IDs. OPF also runs before ordinary push recovery, so cleanup must happen before its divergence check.

Fresh Claude Code linked worktrees have a separate setup problem. Shared Git hooks may exist even though Entire hook dispatch is inactive because the worktree has no Entire settings. Claude user or local settings may cover the current worktree, but .entire/settings.json and .claude/settings.json are the portable project files needed by new worktrees and separate clones.

Checkpoint push repair

For the git-branch v1 backend, pre-push now scans reachable metadata.json history before OPF.

When it finds oversized metadata, it:

1. Fetches the actual v1 tip from the named remote or dedicated checkpoint_remote URL.
2. Verifies that the remote history is clean before treating it as repaired.
3. Rewrites the stale local history with fix(doctor): repair and prevent oversized checkpoint metadata.json blobs #2404's metadata rewriter and serializer.
4. Finds the newest rewritten local tree already present in the remote history.
5. Replays only the local first-parent suffix onto the remote tip.
6. Updates the local v1 ref with compare-and-swap, then uses the ordinary push and retry path.

This path does not force-push.

The shared boundary is identified by tree content rather than commit hash. If the histories have an exact hash merge base, a content match older than that merge base is rejected. This prevents an unrepaired remote from being mistaken for a repaired one.

Replay also checks the resulting tree before creating a commit. If the change is already present at the remote tip, it skips the commit so repeated pushes do not duplicate checkpoints.

The implementation covers the cases that differ from ordinary push recovery:

• An initial push rewrites all available local history, including oversized blobs deleted from the tip tree but still reachable in older commits.
• Cleanup runs before OPF, and the OPF rewrite path reconciles repaired history before checking for divergence.
• Dedicated checkpoint remote URLs use fetched temporary refs instead of remote-tracking refs.
• Cleanup, OPF, URL recovery, bootstrap, and heal fetches use random per-invocation refs, so concurrent hooks do not share one repository-global temporary ref.
• Full initial-history inspection and rewriting are not limited to 1,000 commits. The limit applies only to a local suffix replayed onto an existing remote.
• Scanning includes merge parents and merge-resolution changes. Reconciliation preserves the final tree of replayed merge commits while linearizing the suffix.
• A remote that still contains oversized metadata is never treated as an independently repaired history.
• Rewritten commits continue through the existing commit-signing path.

Shallow history has an explicit boundary. If the shallow boundary is clean, the rewriter preserves it and repairs bloat introduced afterward. If that boundary contains oversized metadata, pre-push stops and asks the user to fetch the missing checkpoint history.

Automatic cleanup applies only to entire/checkpoints/v1. Per-checkpoint Git refs keep their current push behavior.

Worktree setup warnings

entire status, entire status --detailed, entire status --json, and entire doctor now use the same linked-worktree diagnostic.

The warning appears only when a non-prunable sibling worktree proves that the project has both enabled project-level Entire settings and shared Claude project hooks.

It stays silent for ordinary repositories, disabled setups, malformed or unreadable configuration, worktree-list failures, and correctly configured worktrees.

The message distinguishes between two states:

• Entire settings are absent, so Entire hook dispatch is inactive.
• Portable project files are missing, but local Entire settings or Claude user and local scopes may still cover the current worktree.

JSON keeps the existing "error": "not set up" value and adds an optional worktree_setup object. Doctor reports shared Git hooks as installed but inactive when Entire settings are absent instead of reporting them as healthy.

Reading a sibling's settings does not replace the current worktree's process-wide vouched symlink policy.

Performance

A clean v1 push adds one local Git history scan and no extra fetch. A local benchmark over a synthetic 500-commit checkpoint history measured about 137 ms per scan across 10 iterations. The scan has a 10-second timeout.

Verification

Passed locally:

• mise run check
  • formatting and lint
  • race-enabled unit and integration tests
  • Vogon and Roger-Roger deterministic canaries
• go test ./cmd/entire/cli/strategy -count=1
• go test ./cmd/entire/cli/settings ./cmd/entire/cli/agent/claudecode -count=1
• go test ./cmd/entire/cli -count=1
• focused pre-push and linked-worktree regression suites
• git diff --check

No real-agent E2E tests were run.

[MuskanPaliwal]

Hi @karthik-rameshkumar , i have created a draft pr for the follow ups in your pr #2404 . would love your feedback on the direction. thanks :))