Don't log NotFound as a critical error in delete_evicted_splits

[joepio]

Description

SearchSplitCache::delete_evicted_splits logs every remove_file failure as a "critical" error implying an uncounted disk-space leak, but it doesn't special-case io::ErrorKind::NotFound and discards the actual io::Error, so a genuine failure and "someone already removed it" are indistinguishable from the logs.

The sibling .temp cleanup a few lines above in the same file already handles this correctly:

if let Err(io_err) = std::fs::remove_file(&path)
    && io_err.kind() != io::ErrorKind::NotFound
{
    error!(path=?path, "failed to remove temporary file");
}

This PR mirrors that pattern for delete_evicted_splits, and includes the real io_err in the log for the cases that remain.

Why this matters in practice

On a self-hosted single-node deployment (0.8.1) with a very short commit_timeout_secs (aggressive backfill ingest, lots of small-split churn), we run an external sidecar that also removes orphaned split-cache files directly (diffing the cache directory against the metastore's Published set) as a workaround for cache-pollution buildup. When that sidecar wins the race against delete_evicted_splits for the same file, Quickwit's own eviction logs the "critical... disk space leak" message above even though the outcome (file gone) is exactly what was wanted. There's no way to tell that apart from an actual leak without attaching a debugger, since the real io::ErrorKind is discarded.

Even without an external deleter in the picture, any two callers racing eviction for the same split (e.g. overlapping LRU decisions) would hit the same false alarm.

How was this PR tested?

Small, mechanical change mirroring an existing pattern in the same file; no behavior change for genuine (non-NotFound) failures beyond now logging the real error.