Fix sale item deletion and backup admin regressions

[cursor]

Bug and impact

• Draft sale item deletion was exposed as a GET side effect and performed inventory restoration/deletion outside a transaction. A prefetched or malicious link could delete sale items and restore stock, and concurrent delete/cancel requests could inflate inventory.
• Backup restore/delete admin UI was inconsistent with the active views: restore submitted confirm_restore while the view only checked confirm, the template expected a backup object that was not provided, and the delete confirmation template was missing, causing normal backup operations to fail.

Root cause

• The sale item delete endpoint did not enforce POST/CSRF and did not lock the sale/item/inventory rows while restoring stock and deleting the item.
• Backup templates and views drifted after recent backup restore changes, so tests that posted directly to view-only fields did not cover the real browser form contract.

Fix

• Make sale item deletion a POST-only mutation, lock the sale, item, and inventory rows in one transaction, and update the sale item template to render CSRF-protected POST delete forms using the view-provided items queryset.
• Provide restore templates with the expected backup context, accept the real confirm_restore field, and add a delete backup confirmation template plus POST modal form.
• Add targeted regression tests for the sale delete side effect, sale item delete form rendering, restore form fields, and delete confirmation rendering.

Validation

• python3 manage.py test inventory.tests.test_sale_status inventory.tests.test_views.BackupViewSecurityTest inventory.tests.test_services.MemberServiceTest
• python3 manage.py test inventory.tests.test_sales_balance_payment

Both passed; only the pre-existing staticfiles warning for missing /workspace/static was reported.