stagedsync: `prune` means two things — split retention from removing data already copied to files

`prune` currently means two different things, and the collision produced a real bug (#23390).

1. **Retention** — `prune.mode`, `prune.History.Distance`: how much history the node keeps, DB **and** files together. Data is gone; RPC can no longer serve it.
2. **Removing a copy that's already in files** — `PruneTxLookup`, `PruneAncientBlocks`: the data is in `.seg`/`.idx`, so the DB row is a duplicate. Nothing is lost; it's pure space reclaim.

Because both live in the stage `Prune` slot, eviction-style code gets handed `prune.Mode` and reaches for it. That is exactly how `PruneTxLookup` ended up bounding itself by `History.PruneTo`: with `DefaultPruneDistance` the bound sat 240k blocks below what was already pruned, the range was empty by construction, and `BlockTransactionLookup` never shrank (#23199). After the fix `PruneTxLookup` reads `cfg.prune` zero times — it never needed retention config at all.

Other clients have the same collision, so there is no term to borrow: geth *freezes* then prunes; reth **copies** (`copy_to_static_files`) then prunes in a separate crate.

Proposal:

- keep `prune` for retention only
- name the second one after what it removes — suggest **`drop`**, anchored on the state word already in the code (`FrozenBlocks()`): `DropFrozenTxLookup`, `DropFrozenBlocks`. Runner-up `truncate` (WAL precedent: once checkpointed, logs are truncated). `evict` is weaker — cache vocabulary, implies memory pressure, which is not the trigger here.
- stop passing `prune.Mode` into anything that drops file-backed data, so the wrong bound is unreachable rather than merely discouraged

Related: reth calls the move a *copy*, not a move — worth adopting, since "copy" is what licenses deleting the DB side.