Fix destructive sales integrity regressions

[cursor]

Bug and impact

• Viewing a sale detail page could rewrite persisted sale totals to match current line-item totals, corrupting historical completed-sale amounts and member/payment records.
• Draft sale-item deletion accepted GET requests and performed inventory restoration without row locks, allowing accidental/CSRF-triggered deletions and inventory inflation races.
• The checkout UI exposed an unsupported credit payment method; the backend accepted it as a completed sale without receivables or balance accounting.

Root cause

• sale_detail performed repair writes during a read-only page load.
• sale_delete_item was not POST-only and mutated sale/item/inventory records outside a transaction with locks.
• Payment methods were not normalized/validated against backend-supported accounting flows, and the UI exposed credit.

Fix

• Made sale detail read-only.
• Restricted sale-item deletion to POST and wrapped sale/item/inventory updates in an atomic transaction with row locks.
• Normalized and validated payment methods, removed the unsupported credit checkout option, and reject invalid zero totals instead of using a fixed fallback amount.
• Added regression tests for read-only sale detail, GET no-op deletion, and unsupported credit checkout rejection.

Validation

• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment inventory.tests.test_services.MemberServiceTest (14 tests OK; expected GET 405 log, existing staticfiles.W004 warning)
• mkdir -p logs && .venv/bin/python manage.py check (only existing staticfiles.W004 warning)