chore: report negotiated websocket compression in the bulk benchmark

The per-connection-wall test prints the negotiated
Sec-WebSocket-Extensions header; against strfry OkHttp negotiates
permessage-deflate (client_no_context_takeover) out of the box, closing
the 'is compression actually on?' question from the optimization list —
it is, no change needed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018saXqYfAa3RvSJoDXK591R

quartz/plans/2026-07-02-nostrclient-receiver-perf.md

@@ -562,6 +562,14 @@ on download REQs would idle-down against today's reconcile-bound relay and
 the benchmarks could not demonstrate a win (the criterion for shipping);
 revisit if a relay shows download-bound behavior with volatile capacity.
 
+### permessage-deflate: verified active (no change needed)
+
+The per-connection-wall test now prints the negotiated
+`Sec-WebSocket-Extensions`; against nip85.nosfabrica.com (strfry) OkHttp
+negotiates `permessage-deflate; client_no_context_takeover` out of the box.
+Compression was on the suspect list as a 3–5× bandwidth lever for mobile —
+it's already engaged; nothing to code.
+
 ## Recommendations (in order of value/risk)
 
 1. **Move Schnorr verification off the receiver coroutine** in the app's

quartz/src/jvmTest/kotlin/com/vitorpamplona/quartz/nip01Core/relay/prodbench/BulkDownloadBenchmark.kt

@@ -592,6 +592,9 @@ class BulkDownloadBenchmark {
                         webSocket: okhttp3.WebSocket,
                         response: Response,
                     ) {
+                        // Compression matters 3-5x on bandwidth-limited links; report
+                        // whether the relay actually negotiated it with OkHttp.
+                        println("    negotiated Sec-WebSocket-Extensions: ${response.header("Sec-WebSocket-Extensions") ?: "(none — uncompressed)"}")
                         webSocket.send("""["REQ","raw",{"kinds":[$kind],"limit":$pageLimit,"until":$until}]""")
                     }