[pinguinfuss]

Fixes #467.

ClearArtifactCache (and so DiscardArtifact) and UpsertArtifact now write the record and the pending_deletes entry in one transaction, the same way ClearExpiredArtifact does since #428. If queueing fails, the record keeps its old path, so the file is never left in storage with nothing pointing at it.

Eviction gets this from ClearArtifactCache: the path is queued before the file is deleted, and the entry is dropped again once the delete worked. A failed delete leaves it queued for reclaim, as before.

I ran the build against SQLite and Postgres under load: concurrent fetches, stored files deleted and corrupted underneath the proxy, eviction with a tiny max_size, and kill -9 mid-load. None of the three paths orphaned a file.

One trade-off: if only the queue keeps refusing writes while the rest of the database works, a record whose file is missing or corrupt can no longer be cleared or replaced. Every request then refetches from upstream and the new copy is orphaned. In my test with an insert-refusing trigger on pending_deletes, that left more orphans than main does. A real database failure would hit both writes, so I left it as it is.

Not covered here: a crash between writing a fetched file and committing its record in fetchAndCache still orphans that file. That happens on main as well; I can open a separate issue for it.

[andrew]

Please handle replacement-file cleanup when the transaction rolls back because the cleanup queue refuses writes, and cover it through the download entrypoint.