Fix critical sales integrity regressions

[cursor]

Bug and impact

• Viewing a sale detail page could rewrite persisted sale totals from line items, mutating completed historical sales and desynchronizing reports/member accounting.
• Checkout accepted unsupported payment_method=credit exposed in the UI, completing sales with inventory/member side effects but no receivables or settlement handling.
• Invalid non-positive totals could fall back to a hardcoded 855.33, silently corrupting sale amounts.
• Draft sale item deletion was a GET side effect and non-atomic, allowing accidental/CSRF deletion and stock double-restore races.

Root cause

Sales views mixed read and repair behavior, trusted arbitrary posted payment methods because the form only validates remarks, retained a hardcoded emergency amount fallback, and deleted line items without POST/CSRF or row locks.

Fix

• Made sale detail rendering read-only.
• Added payment method normalization/validation, preserved legacy account -> balance, rejected unsupported methods, blocked one-step mixed, and replaced the checkout credit button with supported other.
• Rejected invalid sale totals instead of substituting 855.33.
• Required POST+CSRF for draft line deletion and wrapped sale/item/inventory updates in a locked transaction.
• Fixed the draft item template to use the provided items context and pass member_levels.

Validation

• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment (16 tests OK)
• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_services && .venv/bin/python manage.py check (10 tests OK; only existing staticfiles.W004 warning)