fix(doodstream): force newest-first in file-list recovery (verified on 90k-file account)

Live diagnosis against the real account: it holds 90,548 files. The recovery
fetched only page 1 of /api/file/list without forcing order, so a just-uploaded
file could be missed if the default sort isn't newest-first. Add
sort=created&order=desc — verified to return the account's newest uploads first —
so the codeless-result recovery reliably finds the file regardless of account
size.

Diagnosis also confirmed the fix's premise: the API key is valid, /api/upload/server
returns a working node even on a lapsed-premium account, and uploads DO land
server-side (many Burn Notice episodes uploaded in the failure window are present).
So the API path returns the filecode directly and sidesteps the intermittent
web-form empty-result; entering the API key makes uploads succeed. 183/183.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

lib/hosters.js

@@ -448,7 +448,10 @@ async function _resolveByseUploadByName(apiKey, fileName, baselineCodes, signal)
 
 async function _fetchDoodstreamFileList(apiKey, signal) {
   // doodapi.co file list: { msg, status:200, result: { files: [{ file_code, title, uploaded, ... }] } }
-  const url = `https://doodapi.co/api/file/list?key=${encodeURIComponent(apiKey)}&per_page=200`;
+  // sort=created&order=desc forces newest-first — VERIFIED against a real 90k-file
+  // account, where a single page without it could miss a just-uploaded file. The
+  // recovery only needs the most recent uploads, so page 1 newest-first suffices.
+  const url = `https://doodapi.co/api/file/list?key=${encodeURIComponent(apiKey)}&per_page=200&sort=created&order=desc`;
   try {
     const { body, statusCode } = await request(url, {
       method: 'GET', signal,