Fix critical sales and log audit 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 and sale completion accepted unsupported credit payment values despite no receivables/settlement handling, allowing completed sales with inventory/member side effects but no valid payment record.
• Draft sale item deletion was a GET side effect and non-atomic, allowing accidental/CSRF stock restoration and race-prone inventory updates.
• Log file download/delete audit entries used invalid content_type_id=0, causing failures; delete could remove a file while reporting failure.

Root cause

• Read-only views contained corrective write logic.
• SaleForm does not validate payment_method, and the view trusted raw POST/UI values.
• The delete endpoint did not restrict HTTP method or lock related rows.
• Admin LogEntry.content_type is nullable, but the code wrote a nonexistent FK id.

Fix

• Made sale detail read-only.
• Added payment method normalization/validation, preserved legacy account -> balance, rejected unsupported methods and one-step mixed payments, and replaced the exposed credit button with other.
• Required POST+CSRF for sale item deletion and wrapped sale/item/inventory changes in a transaction with row locks.
• Wrote log audit entries with content_type=None.

Validation

• mkdir -p logs && .venv/bin/python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment inventory.tests.test_views.LogFileViewTest
• mkdir -p logs && .venv/bin/python manage.py check

Note: validation only reports the existing staticfiles.W004 warning for missing /workspace/static; the sale item GET test intentionally logs a 405.