Fix unsupported credit sale settlement

[cursor]

Bug and impact

• The checkout UI exposed payment_method=credit, and the sales backend accepted arbitrary payment method strings because the active SaleForm only validates remark.
• A cashier could complete a sale as credit; the system would mark it COMPLETED, deduct inventory, and update member spend/points without recording receivables, deducting balance, or otherwise settling payment.
• Draft sale completion accepted the same unsupported value.
• Sale detail GET also rewrote persisted totals from line items, which could mutate historical completed sales and desynchronize reporting/member transaction records.

Root cause

• Payment method normalization only mapped legacy account to balance; it did not validate values against implemented Sale.PAYMENT_METHODS.
• The one-step checkout template reintroduced the unsupported credit button.
• sale_detail contained read-time repair logic that wrote sale totals via raw SQL.

Fix

• Added shared payment method normalization/validation while preserving account -> balance.
• Reject unsupported payment methods in sale creation and completion; reject one-step mixed because that flow has no mixed-settlement handling.
• Replaced the checkout credit button with supported other.
• Removed hardcoded 855.33 amount fallback and made invalid totals fail.
• Made sale detail read-only.
• Added regression tests for unsupported credit submission, checkout UI exposure, and read-only sale detail.

Validation

• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_sales_balance_payment inventory.tests.test_sale_status && .venv/bin/python manage.py check
• Result: 14 tests OK; only existing staticfiles.W004 warning for missing /workspace/static.