perf: open the storage screen in seconds and delete many backups at once

[ishaanko]

The storage screen took ten minutes or more to open on a large archive. Each visit copied, hashed, and fully unpacked every ZIP backup, and the worlds screen kicked off the same scan for every world. Deleting backups was also one full confirm-and-wait cycle per backup.

The ZIP store now has a light listing that reads only each archive's filename, checksum sidecar, and embedded manifest. The storage overview, the worlds-screen notice, and the ZIP health check use it; import keeps the full verified listing, and cleanup still verifies the safety-floor archive before it deletes anything. Git repository size measurement also drops from three stats per file to one.

The backup browser gains multi-selection (Ctrl/Cmd click, Shift click, Select all across pages) and a single Delete for the whole selection. The new deleteBackups service call claims every confirmation before touching storage, holds one per-world gate permit, and runs the per-backup deletions as concurrent tasks so Git and ZIP work overlap. One result screen reports how many backups were removed and which ones failed.

Tests cover the light listing against the full one and against broken sidecars, and the batch delete for ordering, all-or-nothing tokens, isolated failures, and real overlap.

Made with Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This update adds batch backup deletion with confirmation handling and concurrent work scheduling.

T-Rex validation blocked

A Java tool package is unavailable: JAVA_HOME is unset and neither java nor javac is installed. Focused deletion checks could not start, so the confirmation-rollback and single-thread execution failures remain open for correction.

Confidence Score: 2/5

Batch deletion can lose a valid confirmation after a rejected request and can stall when work is scheduled through a single-thread executor.

Three independent blocking failures remain in the batch-deletion flow. The responses from ishaanko state that the behavior was fixed, but runtime checks could not start because Java tooling is unavailable; the current-code behavior has not been exercised to establish the claimed outcomes.

Files Needing Attention: src/main/java/dev/ishaanko/worldarchive/recovery/RecoveryDeleteOperation.java

T-Rex Logs

What T-Rex did

• The Java toolchain was missing (JAVA_HOME unset and no java or javac available), so the validation could not proceed and the focused Gradle checks exited before any compilation or test execution.
• The validation shell reported Not connected and reached the maximum-step limit before any Gradle/test or direct compilation output could be captured, and the source artifact was saved while no observed-output artifact existed.
• An observed-output artifact captured the executed Gradle command, the working directory, exit code, and the missing-JDK error, and no source files were modified; only validation artifacts were created.
• The saved test-source capture shows the explicit five-second timeout and confirms JAVA_HOME is unset with no java in PATH, so no runtime behavior could be produced without environment changes.
• The build attempt with Gradle and the direct runtime checks confirmed no JDK is installed or configured, preventing execution of the authored Java validation against the PR or its parent revision.

_{Ran code and verified through T-Rex}

Prompt To Fix All With AI

### Issue 1
src/main/java/dev/ishaanko/worldarchive/recovery/RecoveryDeleteOperation.java:228-247
**Batch confirmation claims are not atomic**

`deleteManyBlocking` consumes each confirmation while walking the request list. If a valid request is followed by an invalid, expired, mismatched, reused, or duplicate request, the later validation throws before deletion starts, but the earlier confirmation has already been consumed and is never restored. The user must prepare the valid deletion again despite the batch making no storage changes. Validate all requests without consuming confirmations, then claim them atomically, or restore all previously claimed confirmations when validation fails.

### Issue 2
src/main/java/dev/ishaanko/worldarchive/recovery/RecoveryDeleteOperation.java:237-243
**Mismatched token escapes rollback**

When a batch request pairs a real confirmation token with the wrong backup ID, `claimConfirmation` removes the token before rejecting the mismatch, while `claimAll` records it for rollback only after validation succeeds. The batch deletes nothing, but retrying that token with the correct backup ID fails as already used.

### Issue 3
src/main/java/dev/ishaanko/worldarchive/recovery/RecoveryDeleteOperation.java:179-220
**Batch deletion waits on its own executor**

`deleteManyBlocking` runs inside the service executor, submits every deletion back to that same executor, and immediately waits in `joinAll`. With a single-thread executor, the sole worker remains blocked in `joinAll`, so none of the queued deletion tasks can begin and `deleteBackups` never completes. Run the per-backup work on a separate executor, or avoid waiting synchronously from the executor worker.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (4): Last reviewed commit: "fix(recovery): let the caller run queued..." | Re-trigger Greptile}