Guard post-commit hook against spurious checkpoints during interactive rebase

[jcleira]

Summary

During git rebase -i, git replays each selected commit and fires the post-commit hook for each one. Partio's post-commit hook will attempt to create a new checkpoint for every replayed commit — even though those commits already have checkpoints and no agent session is running.

Add a guard to the post-commit hook implementation that detects an in-progress rebase and returns early with a no-op. Detection: check for the presence of .git/rebase-merge/ or .git/rebase-apply/ directories.

Note: Partio already guards against --amend re-entry by deleting the state file before the amend. The rebase case is separate — the state file won't be present (so that guard won't trigger), but the hook still fires for each replayed commit.

Why

Without this guard, git rebase -i on a branch with many commits will attempt checkpoint creation for each replayed commit, adding unnecessary overhead and potentially creating spurious checkpoint entries if a stale state file is present.

Source

Inspired by entireio/cli PR #824 (guard session-start hook on duplicate session.created events) and the general pattern of making hooks resilient to git operations that replay commits.

Acceptance Criteria

• Post-commit hook detects in-progress interactive rebase (.git/rebase-merge/ or .git/rebase-apply/) and exits 0 immediately
• Debug-level log message emitted: 'skipping checkpoint creation: interactive rebase in progress'
• Normal commits (no rebase) are unaffected
• Guard does not prevent Partio from operating on commits made after the rebase completes
• Unit test covers the rebase-detection logic with a fake git dir structure

Program file