Give MCP search_tracks disambiguators agents can actually read

[JobDoesburg]

The problem

Searching "sterrenstof" via the MCP search_tracks tool returns 5 results. Three of them are genuinely named "Sterrenstof" — but they have different Spotify IDs because they're different recordings (album version, single, regional release, …). The website shows album covers so the user can tell them apart at a glance. The MCP agent gets:

{ "id": "7D5vAulNfrQV6xEwzgH0OF", "name": "Sterrenstof", "artists": ["De Jeugd Van Tegenwoordig"] }
{ "id": "4PW9WvbhNlrFoThvc7zheh", "name": "Sterrenstof", "artists": ["De Jeugd Van Tegenwoordig"] }
{ "id": "6CGXTNx0MsvLGAxU7gSHRe", "name": "Sterrenstof", "artists": ["De Jeugd Van Tegenwoordig"] }

The agent says, correctly, that it can't tell the difference between them.

A secondary issue: the tool docstring never told the agent that id is a Spotify track ID (opaque, base62) or that the catalog being searched is Spotify's. Some agents try to pass URIs, URLs, or hashes back into request_song.

What this PR does

Add disambiguators to the search results

album (album name), album_release_date (Spotify's YYYY[-MM[-DD]] string), and duration_ms join the existing id / name / artists / image fields on both the REST API (/api/v1/.../search/) and the MCP tool. The two surfaces stay aligned: the MCP exposes a strict subset of what the REST API exposes, never more. With these fields the agent can pick the right "Sterrenstof":

• album="Parels Voor De Zwijnen", album_release_date="2005-09-26", duration_ms=222000 → the original studio album cut
• album="Singles 2005-2010", album_release_date="2010-…" → a compilation
• album="Live At Pinkpop", … → the live recording

Make image resilient

Spotify occasionally returns a track with an empty album.images array. The previous code crashed with a KeyError; now image is None. The front-end already handles image !== null.

Rewrite the MCP docstrings

The tool descriptions now say, explicitly:

• the catalog is Spotify's
• id is a Spotify track ID; pass it through verbatim, don't transform
• results are ordered by Spotify's relevance/popularity ranking — first is the best match Spotify could find, lower-position hits may not even be exact name matches
• two same-name hits are different recordings; use album + release_date + duration_ms to choose; if unsure, ask the user
• Marietje-backed venues return []; that is not "no songs match"
• open.spotify.com/track/{id} is a useful confirmation URL for the user
• request_song should confirm with the user before being called

Test plan

• CI: 218 tests pass, flake8 + black clean, OpenAPI schema validates.
• Via Claude / Cursor: search for a song that exists in multiple recordings (e.g. "Sterrenstof", "Smells Like Teen Spirit"). Confirm the agent sees album, album_release_date and duration_ms, picks one, and asks the user to confirm before queueing it.
• Browser smoke test: open /thaliedje/<venue>/ and search via the website. The dropdown still renders correctly; the underlying /api/v1/.../search/ response now also carries album / album_release_date / duration_ms (additive — the existing fields the front-end consumes are unchanged).
• Marietje venue: search_tracks returns an empty results list as before; the new docstring tells the agent not to interpret that as "no matches".