Fix critical sale and backup data loss paths

[cursor]

Bug and impact

• Viewing a sale detail page rewrote persisted historical sale amounts, which could desynchronize completed sales from balances and member transactions.
• Sale item deletion was a GET side effect without CSRF or row locks, allowing accidental/CSRF deletion and inventory restoration races against completion/cancellation.
• The one-step checkout accepted unsupported credit payment values from the UI and could mark sales completed without any receivables flow.
• Backup media restore deleted live media before copying backup files, so a copy failure could permanently lose uploaded files after DB restore.

Root cause

• Read-only views and destructive actions were sharing mutation logic without method/transaction boundaries.
• Payment methods were accepted from POST without matching the implemented backend flows.
• Media restore performed live delete-then-copy outside the DB restore transaction and without a rollback copy.

Fix

• Made sale detail read-only.
• Restricted sale item deletion to POST, switched the template to a CSRF form, and locked the sale/item/inventory rows while restoring stock and recalculating totals.
• Removed the unsupported checkout credit button and added backend payment method validation.
• Staged backup media before restore and replaced MEDIA_ROOT inside the restore transaction with rollback of the previous media on failure.
• Added the missing backup delete confirmation template and updated restore context handling.

Validation

• . .venv/bin/activate && python manage.py test inventory.tests.test_sale_status inventory.tests.test_sales_balance_payment inventory.tests.test_views.BackupViewSecurityTest inventory.tests.test_services.MemberServiceTest
• . .venv/bin/activate && python manage.py test inventory.tests.test_models

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