feat: require exact project hook review - #201

Review: approved ✅

Directory trust (#197) answers "do I trust this repo's settings". It does not answer "do I trust this repo's hook commands" — and hooks are arbitrary shell that runs automatically around tool calls. Requiring separate, exact-definition hash review for project/local command hooks is the correct additional gate, and it lines up with threat #4 in security-model.md.

What I checked

• Exact-definition hashing with automatic invalidation on change. This is the property that matters: approving a hook once must not approve whatever that hook becomes after the next git pull. Hashing the definition and re-prompting on drift is right, and it's the same reasoning as feat: compose MCP and plugin runtime resources #200's full-tree plugin hash.
• User/override hooks stay trusted — those are the operator's own machine-level config, not repo content. Correct asymmetry; prompting for your own global hooks would train users to approve reflexively, which destroys the value of the prompt.
• Non-command project hooks are preserved, so the gate is scoped to the actually-dangerous kind rather than blanket-blocking hooks.
• One HookTrustStore shared across app-server, CLI REPL/headless, and config diagnostics. Same lesson as feat: add trust-aware config diagnostics #197: a per-client trust store is a per-client bypass.
• hook_review_required diagnostics are value-free and never serialize commands — consistent with feat: add trust-aware config diagnostics #197/feat: surface config diagnostics in clients #198/feat: compose MCP and plugin runtime resources #200, and important here since a hook command line can itself contain secrets.
• deepcode hooks list / trust <hash...|--all> / revoke gives a real escape hatch. revoke matters: approval must be reversible, or the only recovery is hand-editing state files.

Validation: CI green; full suite green locally at the stack tip.