Honor tracks= on /content/download for tag track export

[ditschi]

Problem

The web UI downloads selected tracks from a Tonie card via the tag's audioUrl: /content/download/<ruid>?overlay=…&skip_header=true&ogg=true&tracks=10,11. Only /content/<path> handled tracks=. /content/download/ ignored it and streamed the whole TAF as Ogg (application/octet-stream), which the client then saved under a .zip name.

Change

• handleApiContentDownload now evaluates tracks=. It resolves the tag's source (e.g. lib://…) and calls handleApiContentTrackExport, the same export as /content/.
• If the source is not a local TAF (stream, TAP stream), the route returns 404.

Tests

tests/py/test_track_export.py creates a TAF with 3 tracks in the library and a tag with source: lib://…. It checks both routes, for multiple tracks (zip) and one track (Ogg).

• Without the fix, the tag case fails with application/octet-stream instead of application/zip. This reproduces the report exactly.
• With the fix, all tests pass.

Also verified manually in the web UI (teddycloud_web PR #348): a tag pointing at a 4-track library TAF, tracks 2 and 3 selected, returns a zip with exactly those two tracks via the tag's own audioUrl.

Not included

• An in-process zip (no external zip, UTF-8 filenames, see Track split ZIP corrupts filenames containing special characters #552) will follow in a separate PR.
• An invalid track number still drops the connection instead of returning 4xx. This is existing behavior on both routes.

Refs toniebox-reverse-engineering/teddycloud_web#350

🤖 Generated with Claude Code