[Bug]: Coupon usage can be consumed even when invoice submission later fails

[my-dev-jour]

Bug Description

Coupon usage is incremented before invoice submission fully completes, and the helper commits that increment immediately.

If a later validation, stock, or submit step fails, the sale can roll back while the coupon remains consumed.

Expected Behavior

Coupon usage should only be finalized if the invoice submission completes successfully.

Actual Behavior

Coupon usage can be incremented and committed before the rest of the sale lifecycle succeeds.

Steps to Reproduce

1. Start a sale that uses a limited-use or gift-card-style coupon
2. Trigger a failure after coupon usage is incremented but before the invoice submission finishes
3. Check the coupon usage counter afterward

Impact

• coupon usage counts can drift away from successful invoices
• failed checkouts can permanently consume limited-use coupons
• operators may need manual correction after a failed sale

Suggested Fix

• move coupon usage increment into the same transaction boundary as successful invoice submission
• avoid helper-level commits during coupon consumption
• roll back coupon usage automatically when submission fails

Notes

This is separate from coupon cancel rollback and separate from the race-condition issue. The problem here is that a single failed checkout can still consume usage.

[my-dev-jour]

Re-tested this after the transaction changes in PR #207.

Confirmed on staging with a temporary coupon row:

• the old path using still leaves usage persisted after a later rollback ()
• the fix: make coupon consumption atomic during submit #207 transaction pattern does not persist usage after a later rollback ()
• result:

So this issue does not need a separate code fix if #207 lands. Marking it as covered by #207.

[my-dev-jour]

Re-tested this after the transaction changes in PR #207.

Confirmed on staging with a temporary coupon row:

• the old path using increment_coupon_usage() still leaves usage persisted after a later rollback (old_used_after_failure = 1)
• the #207 transaction pattern does not persist usage after a later rollback (new_used_after_failure = 0)
• result: covered_by_207 = True

So this issue does not need a separate code fix if #207 lands. Marking it as covered by #207.

[my-dev-jour]

Closing as covered by PR #207 based on the staging retest posted above.