fix(debridlink): reuse the file list from the status check

[splitsec2]

Kept small on purpose so it's easy to review.

When a torrent is ready, get_status has already fetched the full record with /seedbox/list?ids= and _handle_torrent_info has checked that every file is at 100%. The retrieval thread was then started without that list, so _process_and_download called _fetch_file_list, which asks the same endpoint again. That second call runs inside the thread's generic except, without the flood and transient error handling the status path has, so a rate limit or a hiccup there sets the phase to error for a torrent that finished fine.

This passes the files already in hand into the thread. _process_and_download already took an optional files argument. The new test starts the thread from a ready status and checks it uses the given list and never calls _fetch_file_list.

Separately, download_url returns a BytesIO, so a whole file sits in memory. AllDebrid, TorBox and Real-Debrid do the same, so I left that for a streaming variant of the shared helper instead of fixing it for one client here.

Ruff and basedpyright are clean and tests/prowlarr passes.

The one red check is the existing clock-dependent test test_a_queued_torrent_asks_for_a_grace_once, which fails on any runner that booted recently. It is fixed in #1426 and is not caused by this change.