ux(planned-purchases): Pause should be visible + reversible, not a silent removal (QA 6.1 follow-up)

[cristim]

QA Planned 6.1 follow-up

Current behavior (bug)

PR #779/#772 fixed the SQL crash by adding paused to the valid_status CHECK constraint on purchase_executions. But now clicking Pause on a scheduled (planned) purchase makes the row silently DISAPPEAR from the list with no feedback and no visible change to the plan. A Pause that looks like a delete is an anti-pattern.

Root cause (suspected)

The planned-purchases list query filters to active statuses (e.g. pending/scheduled) and excludes paused, so paused executions drop out of the rendered list. There is no success toast and no way to un-pause.

Desired behavior

1. Keep the row VISIBLE with a clear Paused status badge (do not drop it).
2. Success toast on pause ("Purchase paused").
3. Add a Resume action to un-pause (paused -> pending/scheduled).
4. Paused executions are excluded from firing but stay listed (or under a Paused filter).
5. Keep the three lifecycle actions distinct: Pause (one execution, reversible, plan stays enabled) vs Disable plan (Disable plan: scheduled purchase removed but plan toggle stays ON (Planned 6.4) #774, whole plan) vs Cancel (terminal).

Notes

• fix(purchases): add 'paused' to valid_status CHECK constraint so Pause succeeds #779 already added the paused DB status and the TransitionExecutionStatus machinery exists from Pause scheduled purchase fails with valid_status CHECK constraint violation (Planned 6.1) #772.

Labels: triaged priority/p2 severity/medium urgency/this-sprint impact/many effort/m type/bug

[cristim]

Verification sweep against main (101f099fb) on 2026-07-27 finds this already resolved.
Paused purchases now stay visible with a badge, a toast, and a Resume action.
Evidence: commit cec0918 (#904).
Recommending close.

[cristim]

Verified resolved at 3c0f8ac: paused executions remain in the planned-purchases list with a Paused badge, pausing shows a success toast, and a Resume action transitions paused back to pending via POST /api/purchases/planned/{id}/resume. Evidence: internal/api/handler_purchases.go:95 and :295, internal/api/router.go:202, frontend/src/plans.ts:745-796 (#904). Residual axes checked: list-status filter includes paused, cancel still accepts paused (:445), run accepts paused (:320); none found. Closing as completed; reopen if the behaviour recurs.