Record a launcher the hook can keep across upgrades

[MongLong0214]

Closes #693.

$ git config --local --get commitlore.bin
/Users/isaac/.local/share/commitlore/v0.8.2/dist/commitlore.mjs

After upgrading to 1.0.1 the repository was still validating commits with the
0.8.2 build while the CLI reported 1.0.1. doctor noticed and said so; nothing
fixed it, because install.sh cannot know which repositories have hooks.

What changed

The wrapper is recorded instead — when it demonstrably launches this build.
It is an absolute path too, so it keeps the property the versioned path was
chosen for (independence from PATH and from any node_modules/.bin/commitlore
above the repository) and simply does not name a release.

A wrapper belonging to a different installation is worse than a versioned path
— it would send the hook to code this install never verified — so an unreadable
or unrelated one falls back rather than guessing. Both directions are pinned.

Fourth instance of one pattern today

.mcp.json             "commitlore"                  the wrapper → followed every upgrade
Hermes external_dirs  .../v0.8.2/hermes/skills      versioned   → broke   (#686)
plugin cache          a copy of the code            a copy      → stalled (#660)
hook commitlore.bin   .../v0.8.2/dist/commitlore.mjs versioned  → this

The configuration that pinned nothing is the one that survived.

Scope

This changes what new installs record. Existing hooks still need
commitlore hooks install re-run, which doctor already prints as its fix line.

Verified by restoring the old resolution: the wrapper case fails. 72 tests
passing across hooks and the new file.

Canonical artifact 036397f2.

[github-actions]

CommitLore — record lint

Trailers: clean — 1 commit in origin/main..5098f406e6af37e190398a0607450d0194559405
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 6 paths; query one path at a time to follow its rename chain (6 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}

[MongLong0214]

Closing: the approach is wrong, and CI caught why.

commitlore.bin: /Users/runner/work/_temp/home/.local/bin/commitlore
outcome: the hook exited 1 under the restricted PATH —
         commitlore: cannot find the CLI this hook was installed with.

Recording the wrapper worked. Executing it did not. The wrapper is a shell script that finds node on PATH, and the hook runs in an environment that deliberately has no useful PATH — which is the entire reason commitlore.node is recorded beside commitlore.bin. A .mjs bundle can be launched with a recorded interpreter; a shell script cannot.

My PR body claimed the wrapper 'keeps the property the versioned path was chosen for'. That was wrong. Being an absolute path and being launchable by a recorded interpreter are different properties, and I asserted the second from the first.

Three local reproductions passed — no wrapper, foreign wrapper, and the unit suite — because my PATH had node in it. The restricted-PATH hook environment exists precisely to make that assumption visible, and it did.

What #693 needs instead

Not this. Either the stub grows a branch that executes a shell-script entry point directly (no recorded interpreter involved), or the launcher recorded is a version-free path to a .mjs that the wrapper also targets — a stable symlink under the data root rather than the bin wrapper.

The second is closer to what the other three instances of this pattern did, and it does not require the stub to learn a new execution mode. Reopening #693 with that.

Nothing about the defect changed: commitlore.bin still pins a version and an upgrade still leaves the hook behind.