Honor file path when download ID is invalid

[esokullu]

Summary

• fall back to an explicitly supplied absolute filePath when downloadId lookup fails, is incomplete, or has no resolved filename
• continue preferring a valid downloadId over a potentially stale path
• clarify the upload_file contract and add regression coverage for the avatar-upload failure shape

Root cause

The Chrome upload handler always prioritized downloadId. When a model supplied both a valid browser-local path and an invented ID such as 0, the handler returned “No download found” before validating or using the path, causing repeated retries and loop detection.

Impact

Instructions such as “Pass that exact absolute path to the browser file-upload tool” now work even if the model accidentally includes an invalid download ID. ID-only failures still recommend list_downloads.

Validation

• targeted upload fallback regression: passed
• JavaScript syntax checks: passed
• git diff --check: passed
• full test suite: 1,427 passed; one unrelated existing failure remains because package.json is 26.0.7 while the newest changelog entry is 26.0.0