`RoSnapshots.delete` could call `dirtySegments.Delete(delSeg)` even when
the target segment was no longer present. That makes repeated deletes or
overlapping cleanup paths turn a harmless "already gone" case into a
nil-pointer failure in snapshot pruning.
This change makes deletion explicitly idempotent: once no matching
segment is found, we return `nil` instead of touching an empty tree. It
also stops the tree walk as soon as the target is found.

The regression test covers both cases that matter here: deleting the
same snapshot twice and deleting a snapshot that does not exist. That
gives a direct proof that the new behavior is safe and matches the
intended delete semantics.

…ntech#21545)

## Problem

- `dirtySegment.close()` (closes seg and idx) can happen on subsegments
once some collation does `OpenFolder`, which uses `TypedSegments` which
closes the subsegments.
- `closeWhatNotInList`-- merge calls this and can crash because of close
earlier.
- maybe user in erigontech#19930 observed
this
- This started happening more after I tried to take snapshot merge off
the build semaphore - erigontech#21526

```
panic: runtime error: invalid memory address or nil pointer dereference
  seg.(*Decompressor).FilePath
  snapshotsync.(*DirtySegment).closeAndRemoveFiles   snapshots.go:420
  snapshotsync.(*RoTx).Close                         snapshots.go:537
  snapshotsync.(*View).Close
```

## Fix

In `closeWhatNotInList`, skip segments with `refcount > 0`: a live
reader still references them, so closing now would invalidate that
reader. They are reaped on a later pass once the reader releases them
(`closeWhatNotInList` already runs on every `OpenFolder`).

`View`/`BeginRo` stays lock-free (erigontech#20490) — the fix is purely in the
close path.

## Test

`TestCloseWhatNotInListVsLiveViewDoesNotCrash` reproduces the crash
deterministically (pure `snapshotsync`, no merge machinery): it builds
sub-segments, opens a `View` over them, drops a covering merged file on
disk, reopens (so `NoOverlaps` removes the subs from the list), and
asserts `View.Close` does not crash. It fails before this change and
passes after.

Co-authored-by: Sudeep Kumar <sudeep.kumar@erigon.tech>