Plugin: lifecycle hooks silently do nothing on installs where slm exists only in the plugin venv

[bgausden]

Problem

Every plugin lifecycle hook calls bare slm and swallows failure, e.g. hooks.json L8, L25, L37…:

"command": "slm hook start 2>/dev/null || true"

Nothing puts $CLAUDE_PLUGIN_DATA/venv/bin on PATH. On a machine with no system install, the MCP server works (it runs the venv's slm via slm-launch), but slm hook mandate/start/checkpoint/post_tool_outcome/… all fail with "command not found", and 2>/dev/null || true hides it. Session-start context injection, checkpoints and outcome capture are lost with no signal to the user.

This is the configuration slm-launch explicitly supports as the fallback ("a plugin-owned venv is the fallback for a machine that has none").

Proposed change

Route hooks through the same binary selection as the MCP server — e.g. a small slm-hook wrapper (POSIX + .bat) that resolves slm exactly as slm-launch does and execs slm hook "$@" — and stop discarding "binary not found" errors (keep || true for hook failures, but log a one-line warning when no slm could be resolved).

Acceptance criteria

• With no slm on PATH and a plugin venv present, running each hook command from hooks.json invokes $CLAUDE_PLUGIN_DATA/venv/bin/slm hook <name> (test with a fake venv slm that records its argv).
• With slm on PATH and SLM_LAUNCHER unset, hooks use the PATH binary (same precedence as slm-launch).
• With neither available, the hook exits 0 and writes one line to stderr naming what was looked for.
• No hook command in plugin-src/hooks/hooks.json calls bare slm.
• plugin/ copy regenerated; build-plugin.mjs --check passes.

Out of scope

• Remote daemons: hooks deliberately only talk to loopback (see post_tool_async_hook.py L50–75); tracked in Feature Request: Support remote SLM daemon in the Hermes native plugin #138.

---

This issue was generated by an AI assistant (Claude) from a read of the code at 5bfa47c, and reviewed by a human before posting.