feat(http): centralize Content-Disposition header generation

[joshtrichards]

• Resolves: #

Summary

Consolidates all Content-Disposition header generation into a single utility class (OC\Http\ContentDisposition). This class is a wrapper for Symfony's HeaderUtils::makeDisposition() with Nextcloud specific multibyte-safe ASCII fallback generator (inspired by Symfony's BinaryFileResponse).

This brings consistency across the codebase for Content-Disposition handling and fixes some problems:

• DownloadResponse used manual strtr() quoting -- lacked filename* for non-ASCII names
• FileDisplayResponse used rawurldecode() (which made no sense at all but happened to work for most filenames, but certainly not all)
• FilesPlugin and files_versions/Plugin had UserAgent sniffing and special handling for IE/Freebox -- unnecessary complexity, legacy, and not done anywhere else
• TrashbinPlugin lacked filename* (non-ASCII) handling
• ImageExportPlugin, MultiGetExportPlugin, TaskProcessingApiController, LogSettingsController used unescaped filenames (not mattering in some cases, but less-than-robust in others)
• Each site had different (inconsistent) quoting/encoding

Changes:

• Adds lib/private/Http/ContentDisposition.php, a thin wrapper around Symfony\Component\HttpFoundation\HeaderUtils::makeDisposition()
• Migrates all call sites to use ContentDisposition::make()
• Removes UA-sniffing constants and IRequest dependency from files_versions/Plugin
• Removes IRequest UA-sniffing from FilesPlugin::httpGet()
• Updates all existing tests and adds ContentDispositionTest
• Updates integration test expected header values

Public API note: DownloadResponse, FileDisplayResponse, and DataDownloadResponse retain their existing constructor signatures. Apps using these classes require no changes -- they simply get correct RFC 6266 headers automatically.

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI