feat: Opt-in track metadata cache, next_track and GET /context/tracks

[palchrb]

Closes the second half of #346.

The API describes exactly one track — the playing one — so a client that wants to show what's coming has only the public Web API, which rate-limits. Meanwhile the daemon's own session already fetches this metadata for playback and throws it away. This keeps it: a bounded in-memory cache feeds next_track in /status and a GET /context/tracks listing for any playable context (playlist, album, artist, show, Liked Songs — built on InferSpotifyIdTypeFromContextUri from yesterday's commits).

Everything is off by default (metadata.enabled, metadata.context_sweep): disabled, no caches are constructed, every helper is a nil no-op (locked in by test), and the endpoint answers 404. Nothing blocks the control loop — enumeration runs in the background behind a ready flag, sweeps are serialised and paced at one batch of 100 per second.

Note: this and #350 both add fields to the status schema and state to AppPlayer, so they conflict trivially at a couple of insertion points. They're fully independent features — review in either order, and I'll rebase whichever is still open as soon as the other lands.

[palchrb]

Aligning with upstream as of today

[ds17f]

NOTE: I'm not a go dev, so it is tough for me to review the code. My AI liked it, but whatever. What I was able to do was test it and I got the following result:

I tested this branch on real hardware. It works.

Test setup

• I built the branch on Fedora with Go 1.26.8 and the ALSA backend.
• I set metadata.enabled: true and metadata.context_sweep: true.
• I connected from a phone with Spotify Connect over zeroconf.
• I played an album (Dire Straits, Love Over Gold).

Result

• GET /context/tracks?uri=spotify:album:... returned all 5 tracks.
• Each track had a uri, a name, an artist name, and a duration.
• The response showed ready=true and cached == length.
• GET /status also showed the new next_track field.
• The log had no 429 error. The data came from the internal spclient API.

Two notes that can help

1. The uri parameter is required, and /status does not give the active context uri. So a client cannot go from "what plays now" to "its track list" without the uri already. This is the same gap as Add context_uri, context_name and the play origin device to /status #380. A small GET /context for the active context would close it.
2. I tested a 5-track album only. The background enumeration and the poll loop (ready=false, then cached < length) are not yet tested with a large playlist.

I can test a large playlist next if that helps.

[devgianlu]

This looks good, I did a large refactor so this needs rebasing. I would also use an exernal module for the LRU: https://github.com/hashicorp/golang-lru