fix: honour CLAUDE_CONFIG_DIR — hooks and always-on tools work on non-default config roots

[borfast]

Problem

Claude Code supports multiple profiles via CLAUDE_CONFIG_DIR, and the agentic installer already detects it correctly (DetectEnv.ts reports the right configRoot) — but the rest of the pipeline ignores what it found. Installing v6.0.5 into a profile at ~/.claude-gc produced:

• All 60 hook commands merged into settings.json pointing at $HOME/.claude/hooks/... — a location where this installer never deployed anything, so every hook event errored on the next session.
• Hooks and always-on tools that did run resolved their own paths back to ~/.claude, reading the wrong profile's settings and writing MEMORY state/observability files into a different profile than the one that loaded them.

This is the same class of issue as #830/#284, but scoped to the new agentic-installer ship model rather than the old full-clone one — per the direction stated there: "The installer hands integration to your own AI, which reads your actual machine (your OS, your paths, your harness) and wires the hooks." This PR makes the shipped tooling deliver that for non-default config roots.

Changes

1. Installer substitution — InstallEngine.rewriteHooksConfigRoot(): at merge time, InstallHooks.ts retargets the default-root spellings ($HOME/${HOME}/~ + /.claude) in payload hook commands at the detected configRoot. No-op when the config root is ~/.claude, so default installs stay byte-identical.
2. Path resolution — hooks/lib/paths.ts getClaudeDir() now falls back CLAUDE_PLUGIN_ROOT → CLAUDE_CONFIG_DIR → ~/.claude (hooks inherit the env var from the harness that loaded them). New LIFEOS/TOOLS/Paths.ts mirrors this for runtime tools, and LifeosConfig.ts defaults derive from it.
3. Hardcode sweep — ~30 hooks/handlers/libs with inline join(homedir(), '.claude', ...)-style fallbacks now route through the shared helpers. Five LIFEOS/TOOLS files (including the lifeos.ts launcher) imported hooks libs via ../../../.claude/hooks/lib/... — a relative path that climbs out of the config root and back in through a literal .claude segment; now the structure-relative ../../hooks/lib/..., which resolves in any profile.
4. User-facing command hints — new displayPath() in hooks/lib/paths.ts; the always-on hooks' guidance messages (memory-health "Run: bun …", writing-gate PangramScore instructions, Art workflow listing, etc.) are built from the resolved path constants instead of a hardcoded ~/.claude, so users are never told to run a command against the wrong profile. Default-root installs render byte-identical messages.
5. install.sh — skills-dir detection probes CLAUDE_CONFIG_DIR before the ~/.claude / ~/.config/claude defaults.
6. Nested skill-payload mirrors (install/skills/LifeOS/...) kept in sync.

Verification

Performed a real install into a live CLAUDE_CONFIG_DIR=~/.claude-gc profile (Linux, Claude Code):

• InstallHooks.ts --apply: all 60 commands rewritten to the profile root (0 left on the default), pre-existing foreign hook entries preserved, backup created.
• All 46 wired command hooks executed with representative event payloads: zero module-resolution or path failures; state/observability files written only under the active profile; ~/.claude left untouched.
• Default-root behaviour: the command rewrite is a no-op and every helper resolves to the same paths as before (bun build clean on all touched files).

Out of scope

• The remaining LIFEOS/TOOLS files not invoked by hooks (plus Pulse and skill tools) are swept in the follow-up PR fix: sweep remaining ~/.claude hardcodes across LIFEOS/TOOLS, PULSE, and skills (follow-up to #1429) #1431, which is stacked on this branch. This PR stays scoped to the runtime-verified always-on surface.