fix: blockdb retention default, rare-name slot filter timeout, address page crash

[pk910]

fix: blockdb retention default, rare-name slot filter timeout, address page crash

Fixes three issues found on the long-running sepolia production instance.

1. Blockdb retention never ran without an explicit cleanupInterval

The pebble/tiered blockdb cleanup worker only started when blockDb.pebble.cleanupInterval
was set. With the field unset (as in the production config), CacheCleanup.Start() logged
cleanup disabled (interval is 0) and the configured per-type retention caps were never
applied — the local cache grew unbounded (38GB observed against 3×5GB configured caps).

Fix: NewCacheCleanup now defaults the interval to 12h when unset. A negative
interval disables the cleanup loop explicitly. Applies to both tiered (cache eviction) and
pebble-authoritative (deletion) mode.

Verified in production: the first cleanup run evicted ~46GB of logical data and pebble's
deletion-triggered compactions reclaimed disk space within minutes (38GB → 17GB).

2. Proposer-name filter on the slots list times out for rare names

GetFilteredSlots evaluates the history-aware proposer-name predicate per row (correlated
EXISTS probes + ilike on the joined validator_names), which is not indexable. With
ORDER BY slot DESC LIMIT n, Postgres walks the slot index backwards testing the predicate
row by row. For a name whose validators proposed fewer slots than the page size (e.g.
"ethrex" on sepolia: 10 new validators, 33 proposed slots ever), the limit never fills and
the scan visits the entire table — measured 77s over 10.75M rows, timing out the page.

The planner cannot pick the proposer-index plan by itself: per-value statistics
overestimate rarely-proposing validators by orders of magnitude (~39k estimated vs 33
actual rows), so the slot-ordered scan always looks cheaper.

Fix: for non-inverted name filters, pre-resolve the matching validator identity set
(current-name indexes + matching history ranges with their snapshot windows, capped at
5000/1000 entries) before building the query:

• pattern matches no current or historic name → return empty without any scan,
• candidate slot rows ≤ 100k (checked with a LIMIT-bounded count probe) → restrict the
  scan to the candidates via an optimization-fenced subquery (OFFSET 0), forcing the
  proposer-index plan,
• dense, truncated, and inverted cases keep the existing query shape, which fills the
  page limit quickly there.

The candidate restriction is a strict superset of the precise predicate, which still
applies unchanged on top. Measured on the production dataset: 77s → 108ms for the
"ethrex" filter. Covered by the existing TestGetFilteredSlotsHistoryNames cases (which
now exercise the candidate-driven shape, including the empty-match early return).

3. /address crashes for addresses unknown to the execution indexer

The address tab loaders (which populate the filter and pager models) only run for accounts
present in the DB (account.ID > 0). For unknown addresses the placeholder account skips
them, and the tab templates dereference the nil models unconditionally:

template: transactions.html:7:64: executing "transactions" at <.TxFilter.Active>:
nil pointer evaluating *models.TransactionsFilter.Active

Fix: buildAddressPageData backfills empty filter and pager models after the tab
loaders, so unknown addresses render an empty page instead of a 500.