Claude tool-permission and hook lockdown (allowed_tools, strict-deny, Pre/PostToolUse)

[Ryan-Atkinson87]

Wire the Claude provider permission layer — the inner security boundary (Spec Principle 4). This is the provider-flag layer that complements the container/network/branch-protection layers; it is not the sole defence, but it must be correct.

Spec §3.2 (Claude permission/lockdown column), §7.4 (Provider permission layer — inner), §7.5 (Explicit prohibitions).

Acceptance criteria

• ClaudeAdapter runs sessions in strict-deny permission mode: anything not pre-approved is denied, never interactively prompted (sessions are non-interactive).
• allowed_tools restricts the surface to coding tools (read/write/run within the repo, dependency install, run tests) per §7.5's "full freedom inside, zero outside".
• A PreToolUse hook blocks destructive/out-of-lane operations: no rm outside the repo, no editing CI/workflow files, no reading .env or secret stores, no file ops outside the project directory (§7.5).
• A PostToolUse hook writes an audit record of each tool call (for the Layer-1 raw capture consumed later in Phase 6).
• Blocks are returned to the engine as a normalised outcome/event, not as an unhandled exception — explicit success and failure paths.
• Tests assert: a blocked op (e.g. read .env, edit a workflow file) is denied by the hook; an in-lane op is permitted; the audit hook fires on an allowed call.

Notes

These provider flags are the inner layer only — the container mount boundary, Squid egress allowlist, and GitHub branch protection (Phase 1 #8, Spec §7.1–§7.3) are the layers that actually hold. Do not treat this as the whole security boundary.

Depends on: #17