v1.3.2 — rate-limit root-cause fixes

Stage 1 of the API-efficiency work. Live diagnostics reproduced the extension freezes: one cold analysis of a big album burned the entire 60/min Discogs budget and died with a 429 after ~19 seconds. Root causes fixed:

• One collection crawl per analysis — the collection was fetched twice concurrently per cold analysis (a third copy inside the survey); taste-fit now reuses the fetched aggregate, and withCache() gained in-isolate single-flight so simultaneous misses on any key share one fetch (also benefits all MCP tools)
• No more doomed 429 retries — the old backoff slept min(retryAfter, 2^attempt) seconds, so every retry landed inside the still-closed window; rate limits now fail fast and honestly (partial surveys, 429+retryAfter to clients)
• Preemptive budget gating — the client tracks X-Discogs-Ratelimit-Remaining and the survey stops launching candidate batches when the remaining budget can't cover them plus an 8-request reserve
• A rate-limited identity lookup now returns 429 + retryAfter instead of a misleading "invalid token" 401

Measured before/after (cold analysis of a 500+-version album): 429 error after 18.9s → complete result in 6.6s. Warm repeats ~0.2s, axis switches ~0.2s (zero Discogs calls) — now locked in by regression tests. 93 tests green.

Full Changelog: v1.3.1...v1.3.2