fix: return 404 for stale cache entries with missing storage objects

[mpecan]

Closes #222

Problem

When a cache entry exists in the DB but its backing storage object has been lost (interrupted upload, manual deletion, lifecycle rule, partial bucket wipe), GET /download/:cacheEntryId threw an unhandled error and returned 500. BuildKit's cache-import client retries on 500 and hangs the workflow instead of falling back to the upstream registry.

Solution

Return 404 when the storage object is missing so clients treat it as a clean cache miss.

The download path has three branches based on storage_locations.mergedAt / mergeStartedAt:

• Merged blob path — adapter.createDownloadStream(merged) already awaits a synchronous existence check in each adapter, so errors surface before any response bytes are written. The outer try/catch just needs to recognize them.
• Parts-streaming paths (fresh entry and mergeStartedAt-but-not-merged) — these were lazy: the generator opened parts only when the consumer began reading, so a missing object would surface after the HTTP response was already framed as 200, truncating the client. Now pre-validated via countFilesInFolder before returning the response stream.

When a stale entry is detected, the server logs a warning and returns undefined; the route yields 404; the existing cleanup task reaps the row on its normal schedule. No DB mutation on the read path.

Changes

• New typed ObjectNotFoundError raised by each adapter's createDownloadStream when the object is missing.
• New private Storage.ensurePartsExist(location) — uses countFilesInFolder to pre-probe before committing to an HTTP response.
• Storage.download() wraps the body in a single try/catch that converts ObjectNotFoundError into undefined (→ 404) and rethrows everything else.
• FileSystemAdapter.countFilesInFolder now returns 0 for a missing folder instead of throwing ENOENT, matching S3/GCS list-by-prefix semantics.
• Removed a dead inner try/catch around the merge-upload promise setup (uploadStream is async, so a sync throw isn't possible).

Testing

• pnpm run type-check ✓
• pnpm run lint ✓
• pnpm run test:run ✓ (new tests pass under filesystem + sqlite locally; full 3×3 matrix runs in CI)

New tests/stale-cache.test.ts covers both parts-streaming paths by wiping storage through Storage.getAdapterFromEnv() so it runs under all three storage drivers in CI:

1. Unmerged entry — save → wipe → restore twice → expect cache miss (exercises `ensurePartsExist` with zero parts).
2. Merged entry — save → restore (triggers background merge) → wait for merge → wipe → restore twice → expect cache miss (exercises the synchronous existence check on the merged blob).

Representative server log from a run confirming the fix:

```
[warn] Stale cache entry 4f31d42e-...: Object not found in storage: 1550524356/merged
[error] Response: GET /download/4f31d42e-... > 404
```

Notes

• No new dependencies.
• No schema changes.
• No changes to any public HTTP contract — stale entries now return 404 where they previously 500'd.