fix(backups): set _deleting before calling deleteInstallationBackup

[Zaldaryon]

The DeleteBackupHandler called the domain function without first marking the backup row as _deleting: true. The domain guard at backupDeletion.ts:28 checks isDeleting, but it was always false because nothing set it before the call. A fast double-click could race two deletes on the same archive.

What changed

ManageInstallationBackups.tsx: dispatch _deleting: true before the domain call. On success the row is removed entirely (existing behavior). On failure, clear the flag so the row returns to its normal state.

This also makes the isDeleting guard in backupDeletion.ts live code rather than dead, which addresses #149 at the same time.

What was tested

• npm run typecheck passes
• npm run lint:ci passes
• npm run test:coverage passes (1110 tests)
• npm run format:check passes on src/ and tests/

Fixes #145
Fixes #149

[Pixnop]

This one should close in favor of #136 rather than merge, and the diff between the two branches makes the case on its own.

#151 is #136's core write (_deleting: true before the domain call) with three things removed: the backup-in-use guard on the clear, the disabled row buttons, and the tests. The first removal is not cosmetic, it reintroduces the exact defect already documented and fixed on #136 in a1d894f. Walk the double-click through this branch: first confirm sets the flag and starts the delete; the row re-renders from config, so a second open-and-confirm hands the domain a snapshot with isDeleting true and the guard correctly refuses with backup-in-use; then this handler's failure path clears _deleting unconditionally, un-sticking the flag the first delete still owns, and a third click sails past the guard into the same double delete. The guard goes live and disarms itself on its first refusal. #136 already holds the reason check that prevents this.

Both PRs edit the same lines of the same handler, so whichever merges second conflicts anyway. Everything here that is correct is already on fix/backup-delete-state, plus the guard, plus the UI half, and the only thing left on #136 is making its middle test click unconditionally.

Two claims in the body also need correcting if any of this survives. Fixes #145 is wrong: that issue is about the auto-prune loop and deleteInstallation removing archives, and neither path is touched here, nor can they see the flag, since BackupRecord carries only id, date and path. And #149 (the dead guard) is genuinely addressed by the write, but through the page's own call only, so it closes with #136 just the same.

[Zaldaryon]

Closing in favor of #136. This branch is a subset of fix/backup-delete-state and reintroduces the backup-in-use clearing defect already fixed there in a1d894f. The _deleting write and the guard live together on #136.