[REQ][typescript-fetch] Name downloaded files from Content-Disposition (return a File instead of an anonymous Blob)

For an operation whose response is a file (isResponseFile), the typescript-fetch runtime returns the body through BlobApiResponse.value():

export class BlobApiResponse {
    constructor(public raw: Response) {}
    async value(): Promise<Blob> {
        return await this.raw.blob();
    };
}

The name the server advertises in Content-Disposition (attachment; filename="invoice-2026-09.pdf") is dropped. Any client that wants to save the download under its real name has to bypass the generated method, call the xxxRaw() variant, read raw.headers and parse the header itself, and every project ends up with its own copy of that parsing.

Every other runtime in this repository already does it for the user:

• typescript generator: ResponseContext.getBodyAsFile() returns new File([data], fileName, { type }) with fileName read from content-disposition (typescript/http/http.mustache).
• Java (okhttp-gson, jersey2/3, apache-httpclient, feign, native, vertx): prepareDownloadFile names the temp file from Content-Disposition.
• Python (api_client.mustache, __deserialize_file): idem.
• C# (ClientUtils, FileParameter): idem.

typescript-fetch is the exception.

Describe the solution you'd like

Keep BlobApiResponse, make it return a File named after Content-Disposition (empty name when the header is absent, type taken from the blob):

async value(): Promise<File> {
    const blob = await this.raw.blob();
    return new File([blob], parseContentDispositionFilename(this.raw.headers) ?? '', { type: blob.type });
}

plus an exported parseContentDispositionFilename(headers) handling the RFC 5987 filename*=UTF-8''... form first and the plain filename= form otherwise.

Backward compatible: File extends Blob, so the generated methods still satisfy their declared Promise<Blob> return type and existing callers keep working; callers that want the name read file.name.

Describe alternatives you've considered

• A new FileApiResponse next to BlobApiResponse: forces a template change in apis.mustache and a choice for the user, for no benefit since a File is a Blob.
• Exposing only the helper and leaving value() unchanged: still leaves every user to call the raw variant.
• Doing it in application code: that is what we do today, duplicated per project.

Additional context

File is a global in browsers and in Node.js 20+ (the CI matrix of the typescript-fetch samples runs Node 20).

PR: https://github.com/OpenAPITools/openapi-generator/pull/24957

Start by reviewing the typescript-fetch BlobApiResponse implementation and the existing filename handling in typescript/http/http.mustache. Check how generated methods consume BlobApiResponse.value(), then verify that the completed behavior preserves Blob compatibility, exposes the requested filename, and handles both Content-Disposition filename forms.