Add a gix integration fixture that constructs a malformed tree with a
directory/file conflict on the same path:

- `a` as a symlink to `.git/hooks`
- `a` as a tree containing `post-checkout -> ../../payload`
- `payload` as an executable file

The tree is created with `git hash-object --literally` so the duplicate
root entries are preserved in the fixture repository.

Add a clone checkout regression test that clones this repository and
asserts that checkout does not write `.git/hooks/post-checkout` through the
attacker-controlled `a` symlink prefix. The test also checks that the
payload itself is checked out and remains executable.

This currently reproduces the vulnerability: delayed symlink checkout
creates `a` first, then reuses the cached `a` prefix when processing
`a/post-checkout`, allowing the final symlink creation to resolve through
`a` into `.git/hooks/post-checkout`.

The fixture is Unix-only at the test level because the exploit depends on
Unix symlink behavior.

Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>

GHSA-f89h-2fjh-2r9q reports that checkout could process a later path beneath
a previously cached leaf without replaying the delegate validation and
directory-creation path for that reused component.

The generic gix_fs::Stack now promotes cached leaves through
delegate.push(false, ...) before entering directory state, so worktree checkout
re-runs collision handling and path validation before using the component as
a parent. The new error handling restores the prior leaf or directory state
if delegate setup or a child push fails, keeping reusable stack state balanced
after recoverable errors.

Regression coverage exercises both overwrite modes in gix-worktree
and the gix-fs delegate callback/error-state transitions. Git baseline
checked in /Users/byron/dev/github.com/git/git at 94f057755b: symlinks.c
check_leading_path() uses lstat-based leading-path checks, and entry.c
unlink_entry() consults that path check before removing entries.

Add a Criterion benchmark for `gix_index::State::from_tree()` to track the
cost of constructing an index from in-memory tree objects.

The benchmark covers the same broad input shapes used by the existing
`to_tree` benchmark:

- a flat tree with 10k files
- a wide/deep tree with 100 directories and 100 files each
- a sparse-directory-like tree with 10k tree entries

The benchmark builds each input once with `gix_object::tree::Editor`, stores
serialized tree objects in an in-memory object database, and then measures
only `State::from_tree()` over those prebuilt trees. Throughput is reported
in logical entries, so regressions from extra sorting, conflict handling, or
tree traversal changes are easier to compare across shapes.

This is especially useful while `from_tree()` performs post-collection
normalization for file/directory conflicts. The desired long-term state is
to preserve the same normalized index invariant while moving closer to
Git’s insertion-time conflict handling, avoiding unnecessary whole-index
work when traversal already produces entries in order.

Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>

This is currently not easily exploitable as anything that interacts
with the worktree goes through a symlink check, which catches this issue
naturally.

The plan is to get closer to how Git keeps the sort order, which detects
such issues more naturally.

Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>