P0: MaxPurchaseAmount permission cap bypassable (upfront-only basis + no retry enforcement) #1494

Summary

Tracking issue for a P0 / critical security bug: two live evasion paths against the MaxPurchaseAmount permission constraint, confirmed against current main. The fix is in review as #1477 (adversarial-review follow-up to #1210 / SEC-01, issue #1141); this issue exists so the P0 is visible in the priority-ordered issue queue independent of the PR.

The bugs (from #1477's analysis, verified on main)

1. Basis was upfront-cost-only, not total commitment. purchaseConstraintSets summed only rec.UpfrontCost across the batch, so a no-upfront (or partial-upfront) RI/Savings Plan — whose UpfrontCost is at/near zero — sails past a MaxPurchaseAmount cap regardless of the true total commitment. An API-key/limited principal could commit far more than their cap allows.
2. Not enforced on retry. (See fix(auth): bind MaxPurchaseAmount to total commitment, enforce on retry (follow-up to #1210) #1477 for the retry path detail.)

Both are money + auth path: a permission constraint that is supposed to bound spend can be bypassed.

Status

• Fix PR: fix(auth): bind MaxPurchaseAmount to total commitment, enforce on retry (follow-up to #1210) #1477 (currently MERGEABLE / CI-clean, awaiting human merge).
• Related: fix(auth): enforce per-permission constraints on execute paths #1210 (SEC-01), issue SEC-01: Per-permission MaxPurchaseAmount and Providers/Services/Regions constraints never enforced on purchase/exchange execution #1141.

Done when

• fix(auth): bind MaxPurchaseAmount to total commitment, enforce on retry (follow-up to #1210) #1477 merges to main, and
• a regression test proves the constraint is evaluated on total commitment (not upfront-only) and on retry, failing pre-fix.

Close this issue when #1477 lands.