Fix backup restore confirmation flow

[cursor]

Bug and impact

The active backup restore page rendered the shared restore template without the backup object it expects, so opening a backup restore page could fail while reversing the form action. If the page did render, the form submitted confirm_restore but the view only checked confirm, preventing operators from restoring backups through the browser.

Root cause

The refactored active backup view passed backup_name/backup_info while the template uses backup.name, and the POST confirmation field diverged from the template checkbox name.

Fix

• Build and pass the backup context used by the restore template.
• Accept the real confirm_restore field while preserving the legacy confirm field.
• Add regression coverage for rendering the restore page and restoring via the UI field.

Validation

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

Both passed; manage.py check only reports the existing staticfiles.W004 warning for missing /workspace/static.