Fix critical sales and log consistency bugs

[cursor]

Bug and impact

• Viewing a sale detail page could silently rewrite persisted historical sale totals, corrupting sales/reporting data from a read-only GET.
• Draft sale item deletion was reachable by GET and ran without row locks, allowing accidental/CSRF-like stock restoration and race-prone inventory updates.
• Unsupported payment methods such as credit could be submitted even though no settlement/receivables flow exists, creating completed sales with unsupported payment state.
• Invalid zero/negative final sales could be completed instead of being rejected.
• Log file download/delete audit entries used content_type_id=0, causing foreign-key failures; delete could remove the file before reporting failure.

Root cause

• Several sales paths trusted navigation/POST state without enforcing read-only semantics, HTTP method safety, supported payment values, or final amount invariants.
• Log file audit records used an invalid content type sentinel instead of Django admin LogEntry's nullable content type.

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 legacy account to balance and rejected unsupported payment methods in create/complete flows; replaced the exposed credit button with supported other.
• Rejected invalid zero/negative final sale amounts.
• Wrote log file audit entries with content_type_id=None.
• Added focused regression tests for these scenarios.

Validation

• python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment inventory.tests.test_views.LogFileViewTest (17 tests OK; expected GET 405 log)
• python manage.py check (passes with existing staticfiles.W004 warning)