Fix destructive sale view side effects

[cursor]

Bug and impact

• Viewing a sale detail page could rewrite persisted sale totals when line-item subtotals differed from the stored totals. For completed sales this corrupts historical payment/audit data, including balance-paid consistency.
• Deleting a draft sale item was reachable via GET. A link prefetch, crawler, or CSRF-style navigation could delete the item and restore inventory without an explicit POST confirmation.

Root cause

• sale_detail attempted to auto-repair mismatched totals during a read-only GET by issuing a direct SQL update.
• sale_delete_item performed destructive work regardless of request method and did not lock the sale/item/inventory rows for the mutation.
• The sale item template rendered a GET link for deletion and referenced the wrong related manager.

Fix

• Made sale detail a pure read-only view.
• Restricted sale item deletion to POST and wrapped the mutation in an atomic transaction with row locks.
• Updated the template to render POST delete forms with CSRF tokens using the provided items context.
• Added regression tests for GET deletion and sale-detail amount preservation.

Validation

• . .venv/bin/activate && mkdir -p logs && python manage.py test inventory.tests.test_sale_status
• . .venv/bin/activate && mkdir -p logs && python manage.py test inventory.tests.test_sales_balance_payment inventory.tests.test_views.BackupViewSecurityTest inventory.tests.test_services.MemberServiceTest

Both passed; only the existing staticfiles.W004 warning for missing /workspace/static was emitted.