Show each plan step's acceptance checks on the review card

[DevMando]

Why this was done

The plan review card is the one moment where the user decides whether to let MandoCode run a multi-step job. Until now that card showed only what each step would do — not how anyone would know it worked.

The CLI side of this change (see the linked MandoCode PR) makes acceptance criteria a first-class part of every plan step: 2–5 concrete, observable checks that define "done" for that step, and that the executor is held to. Those criteria were being generated and enforced, but the Desktop user never saw them. That is the wrong place to hide them — the approval screen is exactly where they matter.

This PR surfaces them, and fixes a related correctness gap in the plan editor.

What changed

1. The plan review card now shows each step's acceptance checks.
Under each step's instruction, the card renders a numbered "Acceptance checks" list. The user can see, before approving, what the agent will actually be measured against — and can reject a plan whose checks are too weak or off-target, rather than discovering that after the run.

2. Editing a step's instruction now resets its acceptance checks.
Previously, editing a step's instruction left the old acceptance criteria attached to it. That produced a genuinely misleading state: the card would show the user's new instruction paired with checks written for the instruction it replaced, and the executor would be graded against the stale ones. Now an edited step's criteria are reset to the instruction the user actually typed, and its "evidence follow-up already used" flag is cleared so the edited step gets a clean run rather than inheriting the prior attempt's budget.

3. Submodule pointer bump to pick up the CLI-side planner work.

Impact for users

• Plan approval becomes an informed decision instead of a formality — the user sees the success criteria, not just the task list.
• Editing a step no longer silently leaves it graded against the wrong criteria.
• No workflow changes, no new settings, no migration. Steps without acceptance criteria (older saved plans) simply render as they always did.

Risk

Low. The rendering change is additive and skips cleanly when a step has no criteria. The editor change touches only the step the user just edited.

Merge order

This PR bumps the MandoCode submodule to the branch commit from the linked CLI PR. Merge the MandoCode PR first, then update this branch's submodule pointer to the resulting commit on main before merging here — otherwise Desktop main would point at a commit that isn't on CLI main.

Related

Depends on the MandoCode CLI PR that introduces acceptance criteria and the final test-and-repair phase.