Capture a rationale alongside each proposal and surface it in review

[Johin2]

Problem

The output of a repair is a diff and nothing else. The user sees what changed but not why the model thought it was wrong, and has to reverse-engineer the intent from the code to decide whether to trust it.

This is the whole review burden. A one-line diff that swaps < for <= is either the correct off-by-one fix or a hack that happens to satisfy the assertion, and the diff alone does not distinguish them.

Proposal

Have the proposer explain itself, and surface it everywhere the diff appears.

• Extend the proposal protocol so a proposer can return a short rationale alongside the source: what the root cause was, why the change addresses it, and what it deliberately left alone.
• Print it above the diff in the CLI, include it in --heal terminal output, and carry it into the repair report from Export the full repair trace: RepairResult JSON + a 'self-heal heal --report PATH' audit log #60 and the PR body from the GitHub Action.
• Keep it strictly optional: a proposer that returns no rationale behaves exactly as today.

Acceptance criteria

• Rationale is captured on RepairAttempt and survives into the report.
• CLI and pytest plugin display it when present, with no layout change when absent.
• Proposers that don't support it are unaffected.
• The rationale is treated as untrusted display text: it is never executed, never used to bypass a safety check, and never parsed for control flow.

Notes

Deliberately advisory. The rationale is an aid to human review, not an input to any accept/reject decision, and it should stay that way. A model that can talk its way past the safety rails is a worse tool than one that cannot talk at all.