new release

`Commit._deserialize` compared a 10-byte slice of each stripped header
line against the 9-byte literal `b"encoding "`, so the comparison never
matched and the branch reading a commit's declared encoding was
unreachable. Every commit parsed from the object database was decoded
with the default UTF-8: `Commit.encoding` reported `UTF-8` regardless of
the header, and the author, committer, and message of a commit written
under `i18n.commitencoding` came back with U+FFFD replacement characters
while `git log` shows them correctly. Re-serializing such a commit also
dropped its `encoding` header and stored the garbled text.

Compare the right slice length so the header is read. Adopt the declared
encoding only when Python has a text codec for it: the identity lines
are decoded with `errors="replace"`, which does not guard against an
unknown codec name, so a commit declaring one would otherwise raise
`LookupError` on attribute access. An unknown name keeps the previous
behavior (the default encoding) and logs the error.

Validated against a repository committed under `i18n.commitencoding =
ISO-8859-1`: `commit.encoding`, `commit.author.name`, and
`commit.message` now match what `git log` shows. Adds regression tests
in `test/test_commit.py` that fail before the change.

I didn't try to fix all the issues with this, let's just make it a little bit
better hoping the code won't be around much longer.

<!-- agent -->
# Known limitations
Commit.encoding still conflates the declared encoding with the codec used for
best-effort decoding. Unsupported or malformed declarations leave the default
encoding—or an earlier accepted declaration—in place, so the resulting attribute
does not faithfully represent the commit’s original metadata. The rejected
header bytes appear in the diagnostic but are not retained on the object.

Fallback decoding with "replace" can irreversibly alter identity and
message content. Reserializing such a commit can therefore change both its
encoding declaration and its content; this change does not provide lossless
round-tripping. Codec validation also checks only that Python accepts the codec,
not that it can decode the actual commit content.

Assisted-by: GPT 6.1 Sol
Co-authored-by: GPT 6.1 Sol <codex@openai.com>

fix(commit): parse the `encoding` header when deserializing

On Windows, `run_commit_hook` runs an extensionless hook through Bash and
passes the hook's path relative to the working tree (`os.path.relpath`).
Bash resolves that path in its own view of the filesystem, which differs
from the Windows one across a mount point. Git for Windows mounts the
user's temporary directory as `/tmp` (`none /tmp usertemp` in its
`/etc/fstab`). For a repository under `%TEMP%` and a `core.hooksPath`
outside it, such as a global `~/.config/git/hooks`, Bash starts in
`/tmp/tmpXXXX/repo`, and `../../../../../.config/git/hooks/pre-commit`,
correct on the Windows side, leads to `/.config/git/hooks/pre-commit`.
Every commit then fails with exit code 127 and
`No such file or directory`.

A relative path that stays inside the working tree cannot cross such a
mount, so it is kept. A path that leaves the working tree (one starting
with `..`) is now passed as the absolute path in POSIX form (`C:/...`),
as is already done for a hook on another drive, when the Bash is Git for
Windows' own or one found on `PATH`: both accept it. The bare `bash.exe`
fallback may be the WSL launcher, which cannot open a Windows absolute
path, so it keeps the relative path as before.

`test_run_commit_hook_outside_worktree_on_windows` now checks the three
cases (outside the working tree with a found Bash, inside it, outside it
with the bare fallback), and `test_pre_commit_hook_outside_worktree` runs
a real hook through a `core.hooksPath` outside the working tree.

Validated on Windows 11 with Git for Windows 2.50.1 and Python 3.14:
`test/test_index.py` passes with an empty global Git configuration (183
passed, 3 skipped, 1 xpassed), and the new command-construction
assertion fails without the change; `ruff` 0.16.9 and `mypy` report no
issues on the changed files; a commit in a repository under `%TEMP%`,
with a global `core.hooksPath` holding a `pre-commit` hook, succeeds
instead of failing with exit code 127.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…-mount

fix(index): pass a Windows hook outside the work tree by absolute path