## Context

`Aggregator.BeginFilesRo()` was made lock-free in erigontech#20462/erigontech#20490, but
physical
file deletion stayed gated by two per-`FilesItem` atomics (`refcount` +
`canDelete`).
Two atomics guarding one destructive action (`closeFilesAndRemove`) is
the TOCTOU
double-free behind erigontech#21384, and a per-file refcount taken *after* the
snapshot
pointer is loaded can't protect the load→pin window by itself.

## What this does

Replaces per-file `refcount`/`canDelete` with MVCC reclamation gated by
a refcount
on the published bundle (`aggregatorVisible`) — the MDBX freelist model
(a page
freed at txnid `T` is reclaimable once the oldest live reader's txnid `>
T`),
realized in Go by reference-counting the generation object instead of
each file.

- Published bundles form an oldest→newest chain; a reader pins exactly
one via
`refcnt`. `refcnt` only grows while a bundle is current, only shrinks
once superseded.
- `BeginFilesRo` does validate-after-pin (one atomic add + re-check),
closing the
  load→pin window. One add instead of dozens of per-file increments.
- Files removed from `dirtyFiles` by a merge/prune are attached to the
outgoing
generation's `retired` set and physically deleted only once that
generation
  (and every older one) drains — reclaimed oldest-first, single owner of
  `closeFilesAndRemove`, no per-file flag, no double-free.
- `DebugBeginDirtyFilesRo` (BuildMissedAccessors) pins the generation
the same way,
so its captured dirty files — including unindexed ones absent from the
visible
  set — are protected for the duration of the accessor build.

`FilesItem.refcount`/`canDelete` are now used only by the forkable
subsystem
(out of scope here).

Design + file lifecycle:
`docs/plans/20260525-lockfree-file-reclamation-spec.md`.

## Status

WIP. Validated locally: `db/state/...` under `-race` (no data races),
`make lint`,
`make erigon integration`.

---------

Co-authored-by: milen <94537774+taratorio@users.noreply.github.com>

…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>