fix(http-client): detect brotli support via libcurl, not PHP extension

[ernolf]

• Fixes a regression introduced in perf(client): enable HTTP/2 and brotli support in internal HTTP client #55433.

Summary

function_exists('brotli_uncompress') checks the wrong layer.
In Guzzle's curl handler, CURLOPT_ENCODING is set to '' which instructs libcurl to decompress all encodings it was compiled with. All decompression happens inside libcurl. The PHP brotli_uncompress() function is never called in this pipeline.

The wrong check creates two silent failure modes:

• PHP extension present, libcurl compiled without brotli → server sends Content-Encoding: br, libcurl passes compressed bytes through, application receives garbled data
• PHP extension absent, libcurl compiled with brotli → brotli is never advertised in Accept-Encoding despite full support

The correct signal is CURL_VERSION_BROTLI in curl_version()['features'], which reflects whether this libcurl binary was compiled with libbrotlidec.
This is also how the Nextcloud News app (FetcherConfig.php) detects brotli support.

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

[ernolf]

/backport to stable33