fix(mrt): improve Brotli streaming performance

[clavery]

Summary

• use Brotli quality 6 by default for dynamic streaming responses instead of Node's implicit quality 11
• flush Brotli after each 32 KiB of uncompressed input so progressive SSR chunks reach the client promptly
• preserve an explicitly configured Brotli quality and all other caller-supplied options
• add regression coverage for the default quality and pre-end() compressed output

Why

Node's implicit Brotli quality 11 is optimized for offline compression. On a production-like 1.6 MB Storefront Next PLP response, it consumed seconds of Lambda time and buffered useful compressed output until the response completed. This also affects traffic through an upstream CDN because the CDN requests Brotli/Gzip from MRT before passing through or transforming the response for the visitor.

Controlled warmed A/B measurements using the same application bundle showed:

Measurement	Original	Patched	Improvement
MRT-origin Brotli total	3.659 s	0.709 s	5.2× faster
MRT-origin post-header tail	3.074 s	0.077 s	39.9× shorter
CDN Brotli total	3.810 s	0.775 s	4.9× faster

The compressed response grew from approximately 102 KB to 125 KB (about 23%) in exchange for eliminating roughly three seconds of response time and restoring progressive delivery. A local compression-only benchmark of the same 1.6 MB document improved from 1,641 ms at quality 11 to 9.45 ms at quality 6.

Validation

• pnpm --filter @salesforce/mrt-utilities test:agent — 559 passing
• pnpm --filter @salesforce/mrt-utilities typecheck:agent
• pnpm --filter @salesforce/mrt-utilities lint:agent
• pnpm --filter @salesforce/mrt-utilities format:check
• pnpm --filter @salesforce/mrt-utilities build

Companion change

Storefront Next currently bundles a separate copy of this streaming adapter. The companion draft PR applies and tests the same fix there: commerce-emu/storefront-next#2648.