fix(purchase): the fire sweep starts new purchases without checking the Lambda time left #1582

#1580 turns the fire_scheduled_purchases sweep on by default (D33). FireScheduledDelayedPurchases (internal/purchase/scheduled_fire.go) fires every due row one after another in a single invocation and never checks the remaining time. The 3m30s + 30s + 30s budget (#1578) covers one purchase, not a whole sweep.

With several slow due purchases, a later one can start near the 300s Lambda limit and be cut off partway. The row stays running until the reaper fails it, and operators get the "outcome unknown, verify before retrying" alert. The stable idempotency keys make a double purchase unlikely, but the record can disagree with what was bought.

Fix options: stop claiming new rows when the time left is below the per-purchase budget (the rest fire on the next tick), or fire one row per run on Lambda. Add a test with a deadline-limited context.

Found by both independent reviews of #1580.