v3.5.2

Fixed

• Stale <musicId> fallback files are now cleaned up even when the resolved file already exists. When a file was first decoded offline (producing a <musicId>.<ext> fallback) and later re-resolved to its proper <artist> - <title>.<ext> name, the superseded fallback was only removed on the fresh-write path. If the resolved-named file already existed on disk (the common state after a reboot), FreeBird took the collision-skip path and left the stale <musicId> file behind forever. The same best-effort cleanup (with all its safety checks) now also runs on the collision-skip path. (Pre-existing orphans from older versions are not retroactively removed; delete those once by hand.)
• scan and watch no longer re-request metadata for already-resolved files. Previously every fb scan invocation — and every fb watch/service initial sweep (e.g. on reboot) — re-hit the NetEase API for all cache files, even ones already successfully decoded in a prior run (their <artist> - <title> output and resolution marker already on disk). With no network at boot this produced a burst of API failures, MetadataFetchFailed markers, fallback <musicId> skips, and ~1-minute-later retries; with network it meant N redundant API calls (rate-limit risk). Both paths now consult the resolution marker before any API call and skip already-resolved files immediately. Failed-status markers still honor their retry-after backoff (a file due for retry is still re-processed), and a changed source or naming template still re-processes. scan and watch now follow the exact same skip rule (a single shared ResolvedMarkerGate).