fix(purchases): updatePlanProgress non-atomic read-modify-write (05-L4)

[cristim]

Problem

updatePlanProgress performs a read-modify-write on the PurchasePlan.CurrentStep field without locking or a database-level atomic increment.

In a multi-tick cron scenario (or if two Lambda invocations overlap on the same plan), both invocations can read the same CurrentStep value, both increment it, and both write CurrentStep+1 — skipping a step or landing the plan at the wrong step index.

Evidence

Report 05, finding 05-L4 (updatePlanProgress non-atomic RMW). Already noted as tracked by issues I-02/I-03 (#1013/#1014) in the fold-1037 plan; filed here as a standalone so it has its own issue for tracking and triage.

Fix

Use FOR UPDATE advisory locking or a database-level SET current_step = current_step + 1 WHERE ... RETURNING * (atomic increment) so concurrent callers converge on the correct step regardless of ordering.

Files

• internal/config/store_postgres.go (or wherever UpdatePurchasePlan / updatePlanProgress live)

Intentionally NOT part of #1037: the CAS-per-execution-row approach chosen in #1037 is sound and is not affected by this plan-level RMW. This is a separate concern at the plan layer.