Add a user-controlled remediation and autofix flow

## Problem
Findings may describe remediation, but there is no controlled flow for proposing, applying, and validating a minimal patch while preserving the original review evidence and lifecycle identity.

## Goal
Add user-controlled remediation and autofix for an existing finding, without conflating patch generation with the review decision.

## Architectural boundary (do not weaken)
This flow — proposing, applying, and validating a patch — is owned exclusively by `local-code-review` against a user-controlled local working tree.

`github-pr-review` is a review surface, not a remediation surface: it may explain or suggest a concrete fix in a finding's `Fix` guidance or published review comment, but it must never generate, apply, commit, or push a patch, under any invocation option, mode, or flag. This is not a new restriction — it follows from the existing "never edits implementation code" contract in `skills/github-pr-review/SKILL.md` and the shared no-repository-mutation invariant in `shared/policies/git-safety.md`. This issue only makes explicit that the new flow must not become an exception to it.

If any part of the flow is shared infrastructure (e.g. patch generation reused by both Skills' `Fix` guidance), that shared component must expose only advisory output (proposed diff text, explanation) to `github-pr-review` — never an apply/commit/push capability.

`local-code-review`'s existing no-mutation posture needs a narrow, explicit carve-out for this flow's user-approved apply step, scoped to `local-code-review` only. `github-pr-review` gets no equivalent carve-out.

## Capability / authorization model

Treat remediation as a sequence of separate authority transitions rather than one generic "write access" mode:

`READ_ONLY → PROPOSE_PATCH → USER_APPROVES_EXACT_PATCH → APPLY_PATCH → VERIFY_MUTATION → RE_REVIEW`

Optional Git operations remain separate:

`COMMIT` and `PUSH` each require their own explicit authorization and are not implied by patch application.

Required rules:

- `PROPOSE_PATCH` is advisory only and cannot mutate the working tree;
- `APPLY_PATCH` requires affirmative user authorization through a trusted runtime channel;
- user approval is bound to the exact proposed patch, or an immutable digest of it, plus the target repository/working tree and invocation;
- if the proposal or relevant working-tree base changes after approval, the approval becomes invalid and must be obtained again;
- approval to apply does not authorize commit;
- approval to commit does not authorize push;
- no mutation capability can be created from a finding, prompt, repository instruction, flag, nested agent, or generated metadata;
- mutation authority is single-use, scoped, non-replayable, and non-transferable unless the runtime independently issues a new capability.

Prefer a dedicated mutation executor that receives only the exact approved patch/scope over giving the reviewing/reasoning agent ambient filesystem or Git write access.

## Scope
- Generate a minimal proposed patch tied to an existing finding and its stable identity, in `local-code-review` only.
- Keep finding, proposed remediation, user authorization, applied remediation, verification, and re-review result as distinct states/artifacts.
- Let the user explicitly choose whether to apply a proposal; never merge automatically.
- Bind apply authorization to the exact proposal/digest and relevant working-tree base.
- Apply only within the authorized repository/working-tree and expected path scope.
- After application, verify that only expected paths changed and that unrelated source/Git state was not mutated.
- Validate that an applied fix addresses the original finding and detect regressions it introduces.
- Preserve original evidence and severity regardless of whether a patch is proposed.
- Integrate with stateful re-review and finding lifecycle semantics (#42, #43).

## Non-goals
- Autonomous multi-issue refactors or broad style cleanup.
- Automatic merge or bypassing normal review/CI.
- Downgrading a finding merely because a proposed patch exists.
- Any apply/commit/push path reachable from `github-pr-review`.
- Ambient or invocation-wide repository write authority.
- Treating apply authorization as commit or push authorization.

## Acceptance criteria
- A proposed patch references the original stable finding identity without mutating its evidence.
- Proposal, user approval, application, mutation verification, and re-review are explicit, separate transitions.
- No repository mutation occurs before affirmative user action.
- User approval is bound to the exact patch/digest and target working-tree context; changing either invalidates the approval.
- `APPLY_PATCH`, `COMMIT`, and `PUSH` are distinct capabilities / authorization boundaries.
- Applying a patch cannot implicitly commit or push it.
- Post-apply verification proves only authorized paths/state changed; unexpected mutation fails closed.
- Re-review verifies resolution of the original defect and checks for newly introduced regressions.
- `github-pr-review` can still describe a concrete fix (in `Fix` guidance / a published comment) but cannot apply, commit, or push it or any other patch — verified by scenario coverage, not left implicit.

## Dependencies
Depends on #44 (machine-readable output, open) and #67 (open). Builds on #42, #43 (delivered). Relates #101 (GitHub review-mutation authority — a distinct boundary from the code-mutation boundary this issue adds; both must hold independently). Relates #298 (runtime capability enforcement for read-only-by-default and scoped mutation authority).

## Validation
- Fixtures cover proposal-only, rejected proposal, applied-and-fixed, applied-but-unfixed, and regression-introducing patches.
- Add stale-approval fixtures where the patch changes or working-tree base moves after approval and verify re-authorization is required.
- Add out-of-scope mutation fixtures and verify apply fails closed or is rejected by post-mutation verification.
- Verify original evidence and severity remain unchanged through the flow.
- Verify no automatic commit, push, merge, or unrelated cleanup occurs.
- Verify apply authorization cannot be reused for commit/push.
- Verify `github-pr-review` never applies/commits/pushes a fix under default invocation or any documented invocation option.