Add thread accounting for CDN download workers

[Copilot]

New Features:

• N/A

Improvements:

• Thread lifecycle management for CDN downloads: Track spawned download threads via Arc<Mutex<Vec<JoinHandle<()>>>> in StreamedFile. Prevents unbounded thread accumulation and ensures graceful cleanup on drop.
  • Periodic cleanup of finished threads before spawning new ones
  • Drop implementation waits for all downloads to complete with debug logging
  • Removes untracked thread spawning (TODO at line 252)

Bug Fixes:

• N/A

Next Steps:

• Consider adding configurable thread pool with concurrency limits for download operations

  ~ ⋖,^><

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• esm.ubuntu.com
  • Triggering command: /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Work on TODO: We spawn threads here without any accounting. Seems wrong. (from psst-core/src/player/file.rs)

Created from VS Code via the GitHub Pull Request extension.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[isaaclins]

@copilot Explain on a High level what exactly happens with this change in a way that a non-developer would understand.

[Copilot]

@copilot Explain on a High level what exactly happens with this change in a way that a non-developer would understand.

Think of it like a restaurant kitchen managing delivery drivers:

Before this change:
When the app needed to download parts of a song from Spotify's servers, it would send out "delivery drivers" (background workers) to fetch the data. However, the kitchen manager wasn't keeping track of which drivers were out, which had returned, or how many were working at once. Drivers would just disappear after completing their job.

After this change:
Now the kitchen manager keeps a list of all active drivers. When a driver finishes their delivery, they're removed from the list. When the restaurant closes (the song file is no longer needed), the manager waits for all drivers to return home before shutting down completely.

Why this matters:

• Prevents the app from creating too many workers and wasting system resources
• Ensures proper cleanup when switching songs or closing the app
• Provides visibility into what's happening (the manager knows how many drivers are out)
• No more "ghost workers" that stick around after they're no longer needed

[isaaclins]

LGTM, tested e2e and approve.