[CHIA-4324] NFT media pipeline 1/3: cache & download infrastructure - #3008

The settings UI stored the cache size limit under the cacheLimitSize
preference key, but on startup the main process reads maxCacheSize - a
key nothing ever wrote - so a user-configured cache size silently
reverted to the 1GB default on every launch. Changing the cache folder
was never persisted at all.

Persist both values from CacheProvider when the corresponding change
events arrive from the main process. The renderer is the only safe
place to write them: prefs.yaml is rewritten from the renderer's full
preferences snapshot on every save, so a value written by the main
process would be clobbered by the next renderer preference change.

On startup the legacy cacheLimitSize key is still honored so existing
users keep their configured limit, and non-positive stored values are
ignored instead of crashing the CacheManager constructor.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Cache-eviction portion of a hardening pass over the NFT media branch:

- Eviction after a completed download now evicts down to the configured
  total-size target while preserving the file that was just downloaded,
  instead of removing an ad-hoc amount that could include it.
- Eviction accounting includes each entry's info sidecar so it matches
  getCacheSize().
- setCacheInfo is awaited, so the cache info returned to callers is the
  saved state rather than a pending promise.
- sanitizeNumber accepts 0 (meaning unlimited) and rejects negative or
  non-finite sizes; the stored preference is accepted when >= 0.

(Split from "fix: harden NFT previews and cache eviction" — the preview
verification portion is in the preview-hardening PR.)

NFT invalidations (driven by nft_coin_added events while the wallet
syncs) delete cache files concurrently with downloads. The cache-size
scan that runs after every download stats each file with no tolerance
for concurrent deletion, so one vanished file rejected the whole scan —
and the download's catch block then overwrote its just-saved CACHED
state with the unrelated ENOENT error. The gallery re-downloaded those
"failed" files, triggering more invalidations and gateway rate limiting
(HTTP 429/504) until the GUI became unusable.

Vanished files are now skipped by both the size and eviction scans,
post-download housekeeping failures are logged instead of replacing the
completed download's state, and per-file sizeChanged bursts coalesce
into one trailing renderer notification instead of a full directory
scan each.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T88GQEqcbujpAKLZy3sKoq

Download timeouts (inactivity and the absolute deadline) aborted the
request without recording a reason, so they persisted as the generic
"Request aborted" — which the cache treats as transient and retries on
every access. Dead hosts therefore stalled every gallery pass for the
full timeout, forever. Timeouts now settle as failed downloads with
their own message; genuine caller-driven aborts remain retryable.

(Split from "Unblock NFT verification from slow metadata and settle
timed-out downloads" — the verification-hook change is in the
preview-hardening PR.)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T88GQEqcbujpAKLZy3sKoq

The download queue was strictly FIFO, so anything the user opened while
a large backlog was queued — an offer preview, a detail page — waited
behind every earlier request. With a cold cache the gallery enqueues
thousands of downloads and dead hosts hold slots for the full timeout,
leaving on-demand previews stuck for many minutes.

The download limiter now runs the most recently requested task first
(per-URL deduplication makes ordering safe), so downloads for what the
user is currently viewing start on the next free slot. RPC paging users
of the limiter keep FIFO ordering.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T88GQEqcbujpAKLZy3sKoq

A download aborted by invalidation or a cache directory change while it
was still waiting in the concurrency limiter previously started anyway:
downloadFile only listened for future abort events and never checked
signal.aborted. The raced transfer held a download slot and, once the
inactivity or deadline timeout hit, could settle the URL with a
permanently persisted timeout error. Reject up front with the same
retryable 'Request aborted' error the mid-flight abort path reports.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Q2tBCuePZJeeCkDDxu1m3

Older builds stored the cache limit under the legacy cacheLimitSize key
and rejected zero at startup, keeping the 1GB default. Accepting zero
from that key would silently turn those prefs files into an unlimited
cache after upgrade. Only the current maxCacheSize key may carry zero
(unlimited); a legacy zero falls through to the default.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Q2tBCuePZJeeCkDDxu1m3

The sizeChanged coalescer cleared its pending flag when the timer
fired, so a burst arriving while a scan was still running scheduled
another scan that overlapped the in-flight one on large caches. Track
the running scan, mark it stale when events arrive mid-scan, and run a
single follow-up scan after it settles so scans never overlap and the
trailing notification still delivers a fresh size.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Q2tBCuePZJeeCkDDxu1m3