feat(cli): install capture hooks into the harness (PROT-8)

[BlakeHastings]

PROT-8: Install capture hooks into the harness

Adds protostar install-hooks, which detects supported harnesses and wires
protostar's capture hooks into them idempotently, so skill use is captured
automatically with no manual config editing.

Jira: https://voidprojects.atlassian.net/browse/PROT-8

Important

This PR is based on feat/PROT-41-bdd-acceptance (the BDD harness), not
main, and targets that branch so the diff is only PROT-8's changes. Once
PROT-41 merges, retarget this PR to main.

Harness provider boundary

Harness integrations live behind an IHarness interface
(HarnessRegistry + ClaudeCodeHarness). Adding a harness is a single class
plus one registry entry; the command and orchestration layers never change, so
churn in any one harness's config format stays contained.

What it does

• install-hooks - interactive multi-select (space to toggle), or
  non-interactive via --harness/--all/--yes. Supports --dry-run and
  --remove.
• capture (hidden) - the stub installed hooks invoke; reads the hook
  payload from stdin and acknowledges. Registry sync is a later ticket.
• Claude Code - wires PostToolUse (Skill tool) and SessionStart via a
  surgical settings.json merge that preserves unrelated settings and is
  idempotent (managed entries are recognised by a marker and replaced, not
  duplicated).
• Lifecycle - install and uninstall now wire and remove hooks
  (--no-hooks to opt out). Removal also lives standalone as
  install-hooks --remove.
• Redirectable roots - harness paths resolve from --harness-home >
  PROTOSTAR_HARNESS_ROOT > CLAUDE_CONFIG_DIR > ~/.claude, which is what
  makes integration testable against a fake harness.

Install bug fix (found while dogfooding)

install previously copied only the single running .exe. That is correct for
a published self-contained single-file binary, but a framework-dependent build
(a local dotnet build) is an apphost that needs its .dll and runtime config
beside it, so the install was broken. install now copies the whole build
output in that case (single file otherwise), and uninstall clears protostar's
own directory safely.

Developer experience

• pstar.ps1 / pstar.sh build-and-run the CLI in place.
• Documented a safe scratch-harness workflow (PROTOSTAR_HARNESS_ROOT ->
  gitignored .dev/) so hook/install commands can be tested without touching
  the real ~/.claude.

Testing

Reqnroll acceptance scenarios (Scenario Outline, one row per harness) cover
install, idempotency, preservation of existing settings/user hooks, dry-run,
remove, the capture stub, and the install/uninstall lifecycle. Full suite green
(15/15) locally.

[ljones491]

Looks good, will approve when retargeted to main. Install command installs separate group from existing hooks, and uninstall correctly avoids wiping non-protostar hooks.

My personal preference would be to group command classes under related features. For example, InstallHooksCommand and CaptureCommand under Hooks/, Install/Uninstall under Installation/, etc. But the current structure works fine.