fix(storage): make cleanup delete the backups it lists

[ishaanko]

Storage cleanup did not delete the backups it listed. For a backup the keep settings do not protect, it removed only the ZIP copy and left the Git snapshot and the catalog entry in place. The backup was still there after the cleanup and after a restart, so the only way to really remove it was the Delete button. The git lfs prune step in compaction also failed in a bare repository, so Git space was only ever freed when every local snapshot went at once.

An unprotected backup is now deleted the same way the Delete button deletes it: Git snapshot, remote copy, ZIP, and catalog record, with a deletion marker so the catalog rebuild at startup does not bring it back. Compaction keeps exactly the LFS objects that a remaining snapshot points at and removes the rest, and it drops the world's history ref so a later rebuild cannot recreate a deleted snapshot without its content. A protected backup that loses its local Git copy keeps its synchronized remote copy in the catalog instead of orphaning the ref on the remote. The preview and confirmation screens say what is deleted where.

Two new integration tests run against real git and git-lfs: unprotected backups are removed everywhere and their LFS objects freed while the kept snapshot still verifies, and a protected backup keeps its remote copy when its local Git copy is evicted.

Prepares release 0.3.7.1.

Made by Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

Not safe to merge until cleanup planning stops promising space that shared Git-LFS objects cannot actually release.

Findings

1.  Shared LFS Space Overcounted ▶

Fix with agent prompt

### Issue 1
src/main/java/dev/ishaanko/worldarchive/storage/management/CleanupPlanner.java:121-127
The cleanup preview assigns each selected Git snapshot an equal share of all repository bytes and treats that share as reclaimable. Shared LFS objects remain when another snapshot still references them, so selecting one snapshot can be reported as enough to meet the storage target even though compaction frees far less space. A repository with two snapshots sharing a 2 MiB LFS object projected 1,062,483 bytes reclaimed and a met target, while cleanup reclaimed only 692 bytes and left the target unmet. Calculate reclaimable Git storage from objects that become unreferenced, or avoid claiming the target is reachable from this average.

---

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

Summary

• Cleanup planning can report that a storage target will be met even when shared Git-LFS objects remain after the selected snapshot deletion.
• The cleanup-space calculation in CleanupPlanner.java needs to account for object reachability before this change can merge.

T-Rex validation blocked

• The repository's Java cleanup integration test could not run because this environment has no Java runtime or JAVA_HOME; the project requires Java 25.

_{Reviews (1) · Last reviewed commit: "fix(git): drop the history ref when comp..."}