v0.5.1 — fix entries gauge on 304 cache loads

Fix

bns_blocklist_entries_by_source{source=...} no longer goes absent after a restart for HTTP blocklist sources that load from cache.

Previously the gauge was only set on the 200 OK fetch path. Any source already on disk in cache_dir with a valid ETag returns 304 Not Modified on its first conditional GET after restart — and the gauge for that source was never populated, even though the list was fully loaded and actively matching. With conditional GETs plus a multi-hour refresh_interval, the gauge stayed absent until the upstream content actually changed (ETag differs → 200).

The 304 path now re-reports the entry count already persisted in the cache metadata (CacheMeta.Entries). A 304 is only reachable when If-None-Match was sent from the cached ETag, so the cached count is current.

Upgrade

Drop-in. No config changes, no behavioural change beyond the metric now being present after a cache-load restart.