Disable plan: scheduled purchase removed but plan toggle stays ON (Planned 6.4)

[cristim]

Symptom (Planned Purchases 6.4)

Clicking "Disable plan" next to a scheduled purchase removes the scheduled purchase from the list, BUT the plan's toggle on the Plans page remains ON. State is inconsistent: the plan is still enabled, yet its scheduled purchase is gone.

Two parts

1. Bug: the state mutations are not atomic. Either:
   • Disabling a plan from the scheduled-purchase row should also flip the plan toggle off, OR
   • It should leave both alone but instead "pause" the scheduled purchase (see Planned Purchases 6.1 for the pause flow).
2. Design question (note in this issue): the QA suggestion is "leaving users the option to enable the plan and the scheduled purchase at a later time". That's a pause-not-delete semantics for the scheduled purchase. The "Disable plan" label may itself be misleading -- consider renaming.

Acceptance (V1 -- fix the state inconsistency only)

• Clicking "Disable plan" from a scheduled-purchase row makes the plan toggle OFF on the Plans page (atomically with the scheduled purchase being removed).
• A regression test exercises the cross-page state: after Disable plan, fetch the plan and assert enabled = false.
• Comment in this issue with the design question about pause vs delete semantics; do NOT change the label or semantics without product input.

Source

Planned Purchases 6.4, exploratory testing 2026-05-27.

[cristim]

Design question worth product input before this merges

The button is labelled "Disable Plan" (and the confirm dialog says "The plan will be paused and no purchases will be scheduled"). The backend operation it calls is DELETE /api/purchases/planned/{id} (which cancels the specific scheduled execution), and the fix in this PR adds setting plan.enabled = false on the parent plan.

A few open questions:

1. Pause vs. disable semantics -- the confirm text says "paused" but the action sets enabled = false, which is the same as the "disable" toggle on the Plans page. A "pause" that can be undone from the same page (resume button) might be the better UX; a disable that requires going to Plans to re-enable is more final. Which is intended?

2. Label consistency -- the button title is "Disable Plan" but the confirmation says "paused." If the intent is a permanent disable (not a temporary pause), the confirm text should say "disabled." If it is a pause, plan.enabled is the wrong field to flip (a dedicated paused flag or simply keeping the existing status=paused on the execution without touching the plan would be more accurate).

3. Other scheduled steps -- when a plan has multiple ramp steps, "Disable Plan" from one row cancels just that execution and disables the whole plan. Is that the right scope, or should it cancel all pending steps for that plan?

The PR as written matches the stated issue (#774: "Disable plan leaves the toggle ON") and makes the mutation consistent. These questions are about whether the semantics of the action are what was originally intended. Happy to adjust once there is product clarity.

[cristim]

Closing — fix shipped as commits 8c5883d (fix(planned-purchases): Disable plan flips plan toggle to OFF atomically) and b4c62d6 (idempotent retry + 404 mapping + deterministic test) on feat/multicloud-web-frontend. PR #781 was auto-closed by GitHub after a rebase produced a zero-diff branch because the commits had already landed on base via an out-of-band merge path.