Allow download of blob for trace and try to get proper filename

[TimoPtr]

Summary

Fixes #6291 and also try to get the name of the file from the frontend whenever we can, otherwise the guessFilename is not really great to get the name of files.

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

[TimoPtr]

The frontend's fileDownload utility creates a blob URL, clicks an anchor element, then immediately calls URL.revokeObjectURL() — all synchronously. In a regular browser the download starts on click, but in Android WebView the download listener fires asynchronously. By the time the native side injects
JavaScript to XHR the blob URL, it's already been revoked, causing ERR_FILE_NOT_FOUND. The XHR had no error handler, so nothing happened — no download, no error.

Fixed by injecting a script that intercepts URL.createObjectURL to keep blob references in a registry, and intercepts anchor clicks to capture the intended filename from the download attribute. When the download listener fires, the blob is read directly from the registry instead of via XHR.

I've used Claude to fix this one

[Copilot]

Pull request overview

This PR addresses WebView blob download failures (notably automation trace downloads) by injecting JavaScript to retain Blob references past URL.revokeObjectURL, and attempts to improve downloaded file naming by capturing the anchor download attribute when available.

Changes:

• Inject a Blob registry/interceptor script on page finish to keep Blob references alive for asynchronous download handling
• Update blob download logic to read from the registry first, falling back to XHR when needed
• Attempt to propagate a better filename from the frontend (anchor download) into the native download flow

[jpelgrom]

window.__blobRegistry is global and accessible to any JS code. As it is a plain map it could allow third party JS to enumerate and get blobs even if it's loaded after the blob is created but before downloaded. Maybe theoretical and we tend to trust the server, but it is a new risk.

Can you improve it to be more secure? My first thought would be to scope the registry to the original function and expose a specific window.__getBlob globally which only works if you have the correct blob URL, so enumeration becomes impossible.

This now has a merge conflict.