Fix destructive sales payment paths

[cursor]

Bug and impact

• Viewing a sale detail page could rewrite persisted sale totals for completed historical sales when line items differed, desynchronizing reports, member spend/points, and balance transactions.
• Draft sale item deletion was reachable via GET and restored stock/deleted line items without transaction locks, allowing accidental/CSRF-triggered writes and inventory races.
• The checkout UI exposed unsupported credit payment, and create/complete flows accepted unsupported payment methods, completing sales without receivables settlement.
• Invalid sale totals could fall back to a hardcoded 855.33, silently corrupting sale amounts.

Root cause

• Read-only detail rendering included repair logic that wrote raw SQL updates.
• sale_delete_item did not require POST and did stock/item/total updates outside a locked transaction.
• Payment method values were copied from POST without validation against implemented settlement paths.
• A fixed-price fallback masked failed total calculation.

Fix

• Made sale detail rendering read-only.
• Required POST/CSRF for draft item deletion and wrapped sale/item/inventory updates in transaction.atomic() with row locks.
• Added payment-method normalization/validation, preserving legacy account -> balance, rejecting unsupported methods, and replacing checkout credit with supported other.
• Rejected invalid sale totals instead of applying the hardcoded fallback.
• Added regression tests for read-only details, GET deletion no-op, unsupported credit rejection, and checkout template payment options.

Validation

• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment && .venv/bin/python manage.py check
• Result: 15 tests OK. Only existing staticfiles.W004 warning for missing /workspace/static; expected GET 405 log from the new regression test.