feat(install): wire SessionStart daemon autostart in ctx-install (close pip-install gap)

[hang-in]

Summary

pip install ctx-retriever && ctx-install is documented as matching the plugin Setup path for daemon autostart (README L88-90: "bge-daemon starts automatically on session open"), but in practice ctx-install was never wiring a SessionStart hook. Daemons did not start on session open for pip-based installs; affected users sat permanently on vec_daemon_down in telemetry.

This PR ships the missing SessionStart wiring so the two install paths produce equivalent results.

Background

The plugin Setup path's plugin/hooks/hooks.json already has a SessionStart entry that probes each daemon socket and respawns if dead — done via a ~700-char inline bash block embedded in JSON. That works for the marketplace path because the JSON is generated.

For ctx-install-managed settings.json, the same logic is easier to audit / version / fix as a maintained script. (One of us already had to land a stale-socket hardening fix in a script-form of this hook locally; that pattern is now in the upstream codebase.)

Changes

File	Δ	Purpose
src/hooks/ensure-claude-vault-daemons.sh	+56 (new)	Maintained autostart script — pipx → venv → graceful exit interpreter detection; pgrep as liveness source of truth; stale sock+pid cleanup before respawn
src/cli/install.py	±28	CTX_HOOKS adds SessionStart row; _hook_entry branches on .sh vs .py extension (bash vs python3)
pyproject.toml	±2	[tool.setuptools.package-data] adds *.sh so script ships in the wheel

Design choices

Why a script, not an inline command (like the plugin Setup path)

• Auditable: 60 lines of commented bash beats a 700-char single-line JSON embed
• Versioned: future fixes (stale-socket handling already needed once) live in git
• Two-path equivalence is preserved: both paths probe sockets and respawn

Why pgrep as liveness source of truth

A *.sock file alone is not a reliable liveness signal — daemon SIGKILL'd / system reboot / terminal close leaves the socket undeleted. The previous [ ! -S sock ] && ! pgrep short-circuits on the stale socket and skips spawn forever. pgrep is the only signal that's actually re-derived per check; on dead, we unlink the stale sock+pid and respawn.

Interpreter detection priority

#	Path	When
1	~/.local/pipx/venvs/ctx-retriever/bin/python	pipx install ctx-retriever (default per README Option A)
2	~/.local/share/claude-vault/venv/bin/python	Plugin Setup path (per plugin/hooks/hooks.json)
3	(graceful exit)	Neither available — BM25-only mode

sentence_transformers must be importable in the chosen interpreter — otherwise we fall through (no spawn, exit 0).

bge-daemon policy

Kept the plugin Setup path's CTX_BGE_ENABLE=1 opt-in (semantic rerank loads a 58s model on first run) so behaviour matches across install paths.

Validation

• bash -n src/hooks/ensure-claude-vault-daemons.sh — syntax OK
• _new_hooks_block() unit-verified to emit:

  "SessionStart": [{ "hooks": [{ "type": "command",
    "command": "bash $HOME/.claude/hooks/ensure-claude-vault-daemons.sh" }]}]

• Live test against a fork-local environment where both daemons had been silently down for 6 days: a single invocation of the new script restarted both cleanly, logs streaming as expected. Stale *.sock + *.pid cleaned automatically.

Backwards compat

• ctx-install is idempotent: re-running on an already-wired settings.json is a no-op (existing dedupes by command string logic in settings_patcher handles the new SessionStart entry the same way)
• --uninstall removes the new SessionStart entry via the same mechanism (no extra changes needed)
• Existing users who manually wired a custom autostart script: their entry survives because it's a different command string

Why this is a maintainer-area change

Per MAINTAINERS.md the install machinery + hook hardening areas land with the second maintainer. Flagging this here so it's clear this isn't algorithm or benchmark territory.

Related: README L88-90 (daemon-autostart promise), plugin/hooks/hooks.json SessionStart inline (the equivalent for the marketplace path).