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