[Perf] LidarrUpdater fetches the same artist's tracks twice per candidate

[egg82]

What problem are you trying to solve?

Two byte-identical fetches in the same iteration:

App/src/main/java/me/egg82/fetcharr/api/model/update/lidarr/LidarrUpdater.java:114

Track allTracks = arrApi.fetch(Track.class, Map.of("artistId", a.artist().id()));   // missing-status check

App/src/main/java/me/egg82/fetcharr/api/model/update/lidarr/LidarrUpdater.java:151

Track allTracks = arrApi.fetch(Track.class, Map.of("artistId", a.artist().id()));   // cutoff check

The first block discards its result and the second re-fetches it, whenever MISSING_STATUS and USE_CUTOFF are both in play.

The two guards - if (missingStatus == MISSING || UPGRADE) at line 113 and if (useCutoff) at line 150 - are independent if blocks rather than else if, so both run whenever both features are enabled.

What the second call costs depends on the cache config, and it's worth being exact:

• Default (USE_FILE_CACHE / USE_MEMORY_CACHE both AUTO, cache dir writable): fetch() bypasses the in-memory ExpiringMap entirely, so the second call reads back the file the first call just wrote and rebuilds the whole Track / TrackResource graph. No HTTP, but a full disk read, JSON parse and DTO reconstruction.
• Caching disabled: a genuine duplicate live API request.

With LIDARR_0_SEARCH_AMOUNT=20 that's 20 redundant deserialisations a cycle on a default install.

What would you like Fetcharr to do?

One fetch per artist per cycle.

Hoist the fetch above both blocks and reuse the local. The two checks read the same data and neither mutates it.