`Commit._serialize` wrote `Actor.name` and `Actor.email` into the `author`
and `committer` headers exactly as given. Each identity is a single line of
the form `name <email> date`, so a line feed or an angle bracket inside
either field moves those boundaries.

A line feed in the author name ends the `author` line and the remainder is
read as further headers. `author` is written before `committer`, so a
`committer` line supplied this way is the one Git and
`Commit._deserialize` use, and an empty line ends the headers so the rest
becomes the message. With the committer pinned by a service and only the
display name taken from its user, the name

    Eve <eve@user.example> 1700000000 +0000
    committer Release Manager <release@corp.example> 1700000000 +0000

    Approved-by: Release Manager

produced a commit that `git log` attributes to committer
`Release Manager <release@corp.example>` with the subject
`Approved-by: Release Manager`, and `git fsck` reported nothing for it.
Without a line feed, `<` in a name or `>` in an email still presents
another email: the name `Release Manager <release@corp.example> x` with the
email `eve@user.example` reads back as `release@corp.example` in both Git
and GitPython.

Git removes these three characters when it formats an identity
(`strbuf_addstr_without_crud()` in `ident.c`), so `git commit-tree` given
the same `GIT_AUTHOR_NAME` cannot write such a commit. Check the name and
email of both identities at the start of `_serialize` and raise
`ValueError` if one contains `<`, `>` or a line feed. `create_from_tree`,
`IndexFile.commit` and `replace` all store the commit through this method,
and the check runs before the object is stored and before `HEAD` or its
reflog are updated. It raises instead of removing the characters, like the
tree and index serializers that reject invalid entries, so a caller is not
left with an identity it did not ask for. The `back-to-the-roots` branch
(#2262) already refuses these characters before calling `git commit-tree`;
this covers the native serializer until then.

Identities without these characters are written as before. `_deserialize`
can return such a field only from a commit that `git fsck` already reports
as `badName` or `badEmail`, for example `A> B <a@b>` or `A <<a@b>>`.
Serializing a commit like that again, for example through `replace()`, now
raises too. None of the 5466 commits in this repository is affected and
`test_serialization` still reproduces every object ID it checks. NUL and
carriage return are left alone: neither moves a field boundary, and Git
keeps a carriage return inside a name.

`test_identity_cannot_alter_headers` covers both fields of both identities
through `create_from_tree` and `replace`. It fails on the previous code and
passes here. The full suite has no new failures on macOS with Python 3.11
(the six `nul\x00name` cases of
`test_submodule_rejects_unsafe_checkout_before_mutation` fail there with
and without this change), and `ruff`, `mypy`, `basedpyright --warnings` and
the documentation build are clean.

fix(commit): reject identity fields that alter commit headers

fix: stop stalled remote commands when their timeout expires

`_validate_repo_path` mirrors Git's `verify_path` for tree and index entry
paths, but it only ever saw the path. Git's check there is mode dependent: an
entry that makes `.gitmodules` a symbolic link is refused, because the
submodule configuration would then be read through the link, from outside the
repository. That is why `git update-index --add --cacheinfo
120000,<sha>,.gitmodules` fails with `Invalid path`, `git read-tree` fails with
`invalid path`, and `git fsck --strict` reports `gitmodulesSymlink`.

GitPython accepted such an entry in both directions. `IndexFile.add` with a
`BaseIndexEntry` of mode `120000` and path `.gitmodules` was stored,
`write_tree` serialized the tree, and `IndexFile.commit` wrote a commit Git
refuses to read back and a server with `transfer.fsckObjects` set rejects.
Coming the other way, `read_cache` and `tree_entries_from_data` accepted the
same entry out of an untrusted repository's index or tree.

`_validate_repo_path` now takes the entry mode and, for a symbolic link,
rejects every spelling Git recognizes: `.gitmodules` with trailing spaces or
periods, the HFS form with ignorable code points removed, and the NTFS short
names `gitmod~1` through `gitmod~4` and `gi7eba~1` through `gi7eba~9`. The
mode is passed at the boundaries that have one: `write_cache`, `read_cache`,
`write_tree_from_cache`, `_tree_entry_to_baseindexentry`,
`IndexFile._preprocess_add_items`, `IndexFile.add`, `tree_to_stream`,
`tree_entries_from_data` and `TreeModifier.add`. Paths reached without a mode,
such as the directories walked by `IndexFile._iter_expand_paths`, keep their
previous behavior, and a regular file named `.gitmodules` stays valid.

Checked against `git update-index --add --cacheinfo` on git 2.52.0 for modes
`100644`, `120000`, `160000` and `40000` over the alias corpus: no path is
left that Git rejects and GitPython accepts. Like the existing `.git` rule the
name is tested per component, so a link below a directory spelled like one of
those aliases is refused as well, which Git happens to allow. Adds regression
tests in `test/test_index.py` and `test/test_tree.py`; `mypy`,
`basedpyright --warnings` and `ruff` are clean.

- speedup additional .gitmodules check

fix(util): reject symbolic links that alias `.gitmodules`