Interactive review mode: accept, reject, or edit each proposal

[Johin2]

Problem

--apply is all-or-nothing and non-interactive. The user reads a diff that has already scrolled past, then decides whether to let it write to their source tree, with no option between "take the whole thing" and "take none of it".

For a tool that writes to files the user has to live with afterwards, that is a coarse control. git add -p exists for exactly this reason.

Proposal

An interactive review mode: self-heal heal ... --interactive.

Present each proposed repair with the diff and, once available, the rationale, then offer:

• a accept and apply
• r reject, and feed the rejection back as context for another attempt
• e open the proposal in $EDITOR and apply what comes back
• s skip this target
• q quit without writing

The reject path is the valuable one: "no, but here's why" is the strongest possible signal to the next attempt, and it is information the loop currently has no way to obtain.

Acceptance criteria

• Each proposal can be accepted, rejected, edited, or skipped independently.
• Rejection feedback reaches the next attempt's prompt.
• Edited source goes through the same safety and verification gates as a model proposal; hand-editing is not a bypass.
• Non-TTY invocation (CI) refuses --interactive with a clear message rather than hanging on stdin.
• Existing non-interactive behavior is unchanged.

Notes

Pairs with the multi-target mode: interactive review is most useful precisely when there are several repairs to triage.