Reduce missing/corrupt SQLite archive-index errors caused by overlapping cache cleanup and repair

[syphar]

This is motivated by sentry errors we see regularly (error returned from database: (code: 14) unable to open database file), and similar errors leading to flaky tests. Also keep in mind: the storage engine only reports to sentry when the problem still happens after 5 retries.

The solutions here are more or less guesses about where these race conditions happen. Also, this PR is more about quickfixes, hoping these reduce the issue.

I'm thinking about a redesign separately, the whole thing feels too complex for me, of course it's also a central part of our webserver.

details

• Await eviction cleanup instead of spawning detached deletion tasks. Explicit invalidations leave file cleanup to the caller, avoiding a second deletion that could remove a replacement.
• Invalidate stale manager entries before repair, then reopen the file inside the coalesced initializer. This allows immediate repair while reusing files another request has already repaired,
  instead of acting on the original force_redownload decision.
• Retry the first failed operation without purging. This gives a concurrently published replacement a chance to succeed; subsequent failures still trigger purge within the existing five-attempt
  limit.
• Delete the index, WAL, and SHM files concurrently, preserving the existing error handling. This might slow down get/set acccess to the moka cache, when it does a maintenance run. It shouldn't happen too often, we do a background maintenance run every 30s.

Successful fast-path lookups remain without a path lock. These changes reduce avoidable deletion and repair churn but do not eliminate all filesystem races.

more tests

• more unit-tests for old/new edge cases
• some optional stress-tests, seeing that they failed on main and are fixed here.