Implement Claude provider adapter via Claude Agent SDK

[Ryan-Atkinson87]

Implement the Claude provider adapter behind the ProviderAdapter interface, using the Claude Agent SDK with a fresh session per task. This is the only adapter built for the MVP (Spec §3.3); proving the full loop end-to-end on it is the goal of this phase.

Spec §3.1 (interface), §3.2 (provider matrix — Claude row), §4.3 (fresh sessions), §16.3 (provider.models tier mapping).

Acceptance criteria

• A ClaudeAdapter implementing ProviderAdapter.run_session, invoking the Claude Agent SDK with a new session per call (no session reuse across tasks).
• SDK events are normalised into NormalisedEvent (reasoning / tool-call / tool-result / output) so the engine/UI never see Claude-specific event shapes.
• usage is populated into UsageReport (tokens in/out, cost, model, duration) from the SDK response.
• artifacts is derived from git (the repo's changed files at session end), not from the model's self-report — uses the git wrapper (Deterministic git operations wrapper bounded to a repo path #9), not the SDK's claimed edits.
• outcome is mapped to completed | blocked | error from the session result, with an explicit failure path (SDK error, timeout) — no silent swallow.
• model is resolved per-role from project.yaml provider.models (planning/implementing/reviewing tiers, §16.3); the resolved model string is passed to the SDK.
• context_files (issue body, spec excerpts) are loaded and supplied to the session.
• No Claude-specific type leaks out of this module's public surface — the engine only ever receives the normalised types from Define ProviderAdapter interface and normalised result/event/usage types #16.
• Unit tests with the SDK call mocked: event normalisation, usage extraction, git-derived artifacts, and each outcome mapping.

Notes

Tool-permission flags and hooks (allowed_tools, strict-deny, Pre/PostToolUse) are wired in #18; this issue accepts allowed_tools and passes it through.

Depends on: #16, #9, #4