hook install writes a junk directory and reports false success when core.hooksPath resolves to a non-POSIX (Windows) path #1385

Summary

When git rev-parse --git-path hooks returns a path that is not a resolvable POSIX directory — e.g. a Windows-style absolute path such as C:\Users\<user>\<repo>\.git\hooks — graphify hook install does not detect this. It path-joins the unresolvable value onto the current working directory, creating a literal junk directory (backslashes and all) inside the repository working tree, writes the hooks there, and prints a false "installed" success message. The real .git/hooks directory receives nothing, so no hook ever fires.

Reproducible in WSL when operating on a repo whose git config has core.hooksPath set (local scope) to a Windows absolute path — a common state when the same repo is used from both Windows-native git and WSL git.

Environment

• graphify 0.8.41 (installed via uv tool)
• WSL2 (Linux) operating on a repo checked out on the Windows filesystem (/mnt/c/...)
• git config --local --get core.hooksPath → C:\Users\<user>\<repo>\.git\hooks
• Consequently git rev-parse --git-path hooks → C:\Users\<user>\<repo>\.git\hooks (unresolvable as a POSIX path from WSL)

Steps to reproduce

1. In WSL, in a repo whose local git config has core.hooksPath set to a Windows-style absolute path (so git rev-parse --git-path hooks returns C:\...\.git\hooks).
2. Run graphify hook install.

Actual behavior

Output (paths genericized):

post-commit: installed at /mnt/c/Users/<user>/<repo>/C:\Users\<user>\<repo>\.git\hooks/post-commit
post-checkout: installed at /mnt/c/Users/<user>/<repo>/C:\Users\<user>\<repo>\.git\hooks/post-checkout

• A directory literally named C:\Users\<user>\<repo>\.git\hooks (with backslashes in the name) is created inside the working tree, containing post-commit / post-checkout.
• The real .git/hooks directory is untouched — no hook is installed where git looks.
• The command exits 0 and reports success.

This junk path is also a hazard: it is an untracked file in the working tree that can easily be git add-ed by accident.

Expected behavior

hook install should validate the resolved hooks directory and either:

• correctly resolve / normalize a non-POSIX core.hooksPath (e.g. translate a C:\... path to its /mnt/c/... equivalent under WSL), or
• fail loudly with a clear error (e.g. "hooks path <x> is not a writable directory on this platform; check core.hooksPath") and write nothing.

It should never path-join an unresolvable value onto the cwd and write a junk directory into the working tree, nor report success when nothing was installed where git looks.

Workaround

If core.hooksPath is pointing at the default hooks location anyway (just expressed as a Windows absolute path), unsetting it makes git resolve $GIT_DIR/hooks relatively, which works from both WSL and Windows:

git config --local --unset core.hooksPath
# then `graphify hook install` installs into .git/hooks correctly

Additionally: merge driver not configured (possible README/behavior mismatch)

The README states graphify hook install "also sets up a git merge driver" so graph.json is union-merged on concurrent commits. On 0.8.41, hook install installed only the post-commit / post-checkout hooks — no merge.*.driver was configured in git config and no graph.json entry was added to .gitattributes. Either the README or the behavior should be reconciled.