fix(metrics): run collection hooks off the /metrics request path

[0xMars42]

Description

The three metric collection hooks registered by metrics_hooks (db,
static_file_provider and rocksdb report_metrics) run synchronously
inside the /metrics request handler. Each is wrapped in
throttle!(5 min), and when it fires it walks its backing store. The
static file provider in particular iterates every jar of every segment,
which grows as the node accumulates static files and takes several seconds
on large datasets.

Because that work runs on the HTTP handler future, the scrape is blocked
for the whole walk. As reported in #24566, a Prometheus/VictoriaMetrics
scraper with a scrape_timeout shorter than the walk drops a sample every
5 min (periodic dashboard gaps), and the floor keeps rising as static files
accumulate.

Fix

Decouple collection from rendering, as the issue suggests:

• Add a periodic background task (start_metrics_collection_task) that
  runs the hooks on the blocking pool (spawn_blocking), so the walk can
  never starve the async runtime.
• /metrics and the push gateway now only render the already-collected
  gauge values; neither runs hooks inline anymore. The request handler has
  bounded, dataset-independent latency.
• The hooks keep their existing throttle!(5 min) gate, so the
  report_metrics cadence is unchanged; only the thread it runs on
  differs. Collection stays owned by the hooks, and the task just pumps
  them off the request path.

The push gateway task already ran these same hooks on a background task via
the same TaskExecutor, so this reuses an established pattern and also
stops that path from blocking on them.

Testing

Added metrics_endpoint_is_not_blocked_by_slow_hook: it registers a hook
that sleeps 3 s and asserts /metrics still responds within a 500 ms
client timeout and under 1 s wall clock. It fails on the previous
synchronous path (the request times out) and passes with the background
collection.

cargo test -p reth-node-metrics (4 passed), cargo +nightly fmt --check
and cargo +nightly clippy --all-targets --all-features -D warnings are
green.

Closes #24566