#2770 gatorwalk-factory: keep a person's plan feedback and hand it to the next plan

A person's feedback on a plan is issue-lifecycle's main loop, and gatorwalk drops it.

What issue-lifecycle does

iterate (extensions/models/issue_lifecycle.ts:1342-1490) takes feedback as text. It:

• writes each round to the versioned feedback resource (:470, :1411-1437);
• stores the revised plan with feedbackIncorporated, the cumulative list of every round (:1440-1450);
• posts plan_revised with the version, the round number and the feedback (:1470-1484).

The next plan is built from all of it.

What gatorwalk does

• plan-review.revise is a manual advance, and advance takes no note (extensions/models/work_item.ts:269-289).
• The only place feedback can go is a decline note on plan-approval. It stays in the run record and status (_lib/gates.ts:456-461), counts only for that stage and cycle, and is never projected: a decline is not an entry trigger (_lib/projection.ts:213-220).
• The plan artifact has no field for the feedback it answers (lifecycles/swamp-extensions.yaml:257-281).
• plan injects only classification (:255-256). After rework or revise, the planning agent is not handed the review findings, the earlier plan or the feedback, even though its prompt says to address the last review's findings (:253-254).

Why it matters

In the pilot, the first time a person says "change the plan like this", the text lives only in the chat. It does not reach the next planning pass, the Lab history, or the summary report.

Fix direction

These changes are YAML only:

• plan injects [classification, plan, plan-review, plan-feedback].
• A plan-feedback evidence ({feedback, round}) is declared on plan-review. revise gains an evidence-recorded gate on it this cycle, so a revision always carries its reason.
• The plan schema gains an optional feedbackIncorporated: string[].
• plan_revised fills from the plan payload.

Decision for the implementer: use that evidence, or give advance (or manual transitions) a journaled note that CEL and the projection can read. A note would help every manual exit (reclassify, rework, recheck, new-pr). The evidence needs no format change.

resolve_findings is not part of this. It is covered by re-recording the review (swamp-extensions.md:105-111).

Done when

• A walk test shows that revise is refused without feedback, and that the next plan dispatch packet injects the feedback, the prior plan and the review.
• Against the Lab fake, plan_revised carries the feedback.
• swamp-extensions.md's "Plan feedback (iterate)" row says how the feedback is kept.