downloader: record and validate download filters across preverified.toml scans

## Problem

Each time `preverified.toml` is scanned to determine which snapshots to download, a set of filters is applied (prune mode, chain, step size, capability flags, etc.). These filters are currently not recorded anywhere. If they change between runs — e.g. the user restarts the node with a different `--prune.mode` or switches branch — the download selection will silently differ from what was used in previous scans.

## Proposed behaviour

When `preverified.toml` is scanned for download planning:

1. Compute and persist the full set of filters applied (prune mode, chain, relevant flags) alongside or within the snapshot directory.
2. On each subsequent scan, compare the current filter set against the recorded one.
3. If they differ: **warn** the operator that the filter set has changed.

The warning is the primary output of this issue. The expectation is that the existing integrity checks — infohash mismatches causing re-download and extraneous files requiring a reset to proceed (see #19716) — will handle the downstream consequences in most cases. The filter-change warning gives the operator early, readable signal about *why* those checks may subsequently fire.

## Related issues

- #19714 — preverified source selection on main node (companion issue)
- #19716 — error on extraneous snapshots when resuming incomplete sync
- #19669 — restart instability: changing prune mode on restart caused unexpected download behaviour
- #19435 — AddTorrentsFromDisk race; stresses the importance of a canonical clean state before sync