Plan context panel and feedback policy controls

Provenance stamp: This issue was triaged on June 13, 2026 as part of the older-than-two-month GitHub issue triage exercise.

Source issues: #7, #23, #108, #431

## Summary

These issues all ask for better control over what context surrounds a plan review and what feedback gets sent back to the agent. Users want to understand how the plan was produced, guide what approval or denial means, and prevent repeated plan revisions from losing prior decisions.

## What the source issues requested

- #7 requested custom instruction hooks for approve and request-changes behavior. The user wanted to shape what the agent does after review, such as saving a spec or following custom approval instructions.
- #23 requested richer plan metadata, including files read, tools used, MCP interactions, subagents, planning iterations, and the initiating user prompt.
- #108 requested a way for replans to ignore already-completed tasks so denial feedback does not waste tokens repeating work that is done.
- #431 requested context anchoring for plan decisions so rejected approaches, constraints, and reasoning survive across iterations and sessions.

## Triage determination

These are not separate features in practice. The product question is: what context does Plannotator show to the reviewer, and what structured policy does it send back to the agent? A single tracking issue can cover the plan context panel, feedback customization, and decision-memory behavior without scattering the work across multiple small mechanisms.

## Acceptance criteria

- The plan review UI can show relevant planning context when available, including the initiating prompt, files read, tool summary, and subagent references.
- Context capture uses actual session or transcript data where possible and does not invent unavailable metadata.
- Approval, denial, and request-change messages can be configured without editing source code.
- The UI makes the active feedback policy visible before the user sends it.
- Repeated plan iterations can preserve rejected alternatives and key decisions in a durable form.
- Feedback can omit, summarize, or mark already-completed work so the agent does not treat it as still pending.
- The old source issues can be closed once this issue contains the source-specific requirements and the supported policy model is clear.

## Notes

The current configurable feedback pipeline may already cover part of #431. This issue should identify what remains productized by default and what is intentionally left as user configuration.