enrich: FreqBlog 'queued' (202) responses are misclassified as failed

[gnujoow-bot]

Summary

FreqBlog /lookup returns HTTP 202 queued when a track is not in the catalog and an on-demand ingest has been triggered (typically ready in ~15s). enrich.py treats queued as a terminal state:

elif outcome.status == "queued":
    db.bump_enrich_attempt(track.spotify_id, MAX_ATTEMPTS)
    counts["queued"] += 1

bump_enrich_attempt(..., MAX_ATTEMPTS) pushes the track to the attempt limit, so it is never retried — even though a subsequent re-lookup would return ok with full BPM/key/energy data.

Impact

Playlist/album tracks that are not pre-indexed in FreqBlog are permanently marked failed (or terminal enriched) and never enriched, even though the data becomes available seconds later.

Expected

queued should schedule a retry (e.g. keep pending with a short backoff / re-enqueue after ~15–30s), not mark the track failed.

Reproduction

1. Run enrich on tracks not in FreqBlog's catalog.
2. Observe 완료: ... 부분 보강(재조회 예정) N곡, 실패 M곡 where the "failed" ones were actually queued on-demand ingests.
3. A manual re-lookup of those tracks ~30s later returns ok.