index: improve file/dir conflicts handling - #7332

Problem

git_index_add silently ignores a file/directory conflict: adding a blob at a path that collides with an existing tree entry (or vice versa) should replace the conflicting entry the way git does, but the stale entry is left in place and the add "succeeds".

Cause

In index_existing_and_best() (src/libgit2/index.c), when the entry is not already in the index, index_find has computed pos — the sorted insertion position — but the function discards it and hardcodes the out-param to 0:

    *existing = NULL;
    *existing_position = 0;   /* discards the computed pos */
    *best = NULL;

The sole caller, index_insert, passes that position into check_file_directory_collision() → has_file_name(), which scans forward from it. Starting the scan at 0 instead of the real insertion position means an earlier-sorting sibling entry can end the prefix scan before the actual conflict is reached, so the collision is never found. The bug is only observable when the insertion position is non-zero — which is why the existing collision tests (each with a single prior entry, whose insertion position happens to be 0) don't catch it.

Fix

Report the real insertion position on the not-found branch:

-    *existing_position = 0;
+    *existing_position = pos;

pos is valid here: git__bsearch sets it to the insertion index even on GIT_ENOTFOUND, and the stage-matching loop just below already relies on it. index_existing_and_best is static with one caller, and nothing depends on the old existing == NULL ⇒ position == 0 behaviour.

Test

Adds add_blob_with_conflicting_dir_not_at_start, which seeds sibling entries so the conflicting blobtree lands at a non-zero insertion position, reproducing the missed conflict that the fix resolves.

Fixes #7160.