command/albumart: add "file" field with the artwork path

[CamilleScholtz]

Summary

Closes #2397.

The albumart response currently exposes only the artwork's size and bytes. Clients have no way of knowing which file in the song's directory MPD picked (cover.png / cover.jpg / cover.jxl / cover.webp). This adds a file field with the resolved artwork path, which is useful for:

• Artwork comparison — recognising that two tracks share the same artwork file.
• Caching — using the artwork path as a stable cache key instead of hashing bytes.
• Change detection — invalidating caches when cover.jpg is replaced on disk.
• Debugging / transparency — making it visible which candidate file was chosen when several are present.

Example::

albumart foo/bar.ogg 0
file: foo/cover.png
size: 1024768
binary: 8192
<8192 bytes>
OK

Implementation notes

• read_stream_art() now takes both an open directory (still the cache key) and a display directory (used for the response). Their values diverge only for the database (RELATIVE) case, where the open directory is the storage-mapped path while the response should reflect the path as the client addressed it.
• The basename is read from the cached InputStream's URI via is->GetUriView(), so subsequent chunked requests that hit the LastInputStream cache continue to report the same file: value without extra plumbing.
• RealDirectoryOfSong() now walks the relative and resolved directories in lockstep so CUE-sheet ../ resolution applies to both forms.
• For PATH/ABSOLUTE URIs the open and display directory are the same, so the response prints the absolute path or URL.

Test plan

Verified manually against a test fixture with cover.png next to a song, on macOS:

• albumart foo/bar.ogg 0 → file: foo/cover.png
• albumart /abs/path/foo/bar.ogg 0 → file: /abs/path/foo/cover.png
• Chunked second request (cache hit) reports the same file:
• offset > size still returns ACK [2@0] {albumart} Offset too large (no file: line on error)
• No cover present still returns ACK [50@0] {albumart} No file exists