fix(git): refuse to commit when nothing is staged

[ConnorMoss02]

Closes #4762

git_commit returns Changes committed successfully with hash <sha> even when nothing is staged.

repo.index.commit() writes a tree from the index unconditionally — GitPython has no --allow-empty gate — and the return string cannot be false:

def git_commit(repo: git.Repo, message: str) -> str:
    commit = repo.index.commit(message)
    return f"Changes committed successfully with hash {commit.hexsha}"

An agent edits files, calls git_commit without git_add (or after a git_add that matched nothing), and gets a hash. It reports the work as committed. The working tree is still dirty, HEAD still holds the old content, and the repo now carries an empty commit. Nothing in the response distinguishes that from a real commit.

status before:  M a.txt
returns:        Changes committed successfully with hash efd05335b0ab
empty commit:   True        # parent tree == new tree
status after:   M a.txt
a.txt in HEAD:  v1          # the edit was never committed

git commit itself refuses this: "no changes added to commit".

Fix

Raise when the index matches HEAD, matching git's default. Two cases git does allow are preserved:

• the first commit on an unborn branch, where there is no HEAD to compare against
• an empty merge commit, which git permits while MERGE_HEAD exists — a conflict resolved back to HEAD's content leaves the index matching HEAD, and that commit is legitimate

No new parameter: git requires --allow-empty explicitly, so refusing by default matches it.

Tests

Six, covering both directions. Three assert the refusal (unstaged edit, clean tree, untracked-only) and fail with the source change reverted. Three assert it does not over-refuse (staged deletion, unborn branch, empty merge commit) and pass either way.

53 passed in src/git.