## Summary

A JSON-RPC batch containing 2+ streamable methods ran each call on its
own goroutine, and each one invoked the shared gzip-streaming flush hook
installed on the request context. `gzipResponseWriter.Flush` is not safe
for concurrent use, so calling it from multiple goroutines raced on the
underlying `gzip.Writer` and could dereference a nil flate compressor,
crashing the node.

Batch sub-calls write into private per-item buffers rather than the HTTP
response writer, so the hook was never useful there in the first place.
Mask it out of the context used by batch sub-call goroutines instead of
hardening `gzipResponseWriter` itself, since it remains owned by a
single goroutine everywhere else.

Also hardens the hook mechanism itself: `WithGzipStreamingHook` now
panics if ever called with a nil hook, and `runMethod` guards the flush
call with `ok && flush != nil`, so the mechanism doesn't rely on the
hook always being stored as an untyped nil to stay safe.

Fixes #22334

## Tests

- Added `node/rpcstack_gzip_batch_race_test.go`
(`TestGzipHandlerBatchConcurrentStreamableFlush`): sends a real JSON-RPC
batch of 8 calls to a streamable method through the actual gzip
middleware and `rpc.Server`, with `Accept-Encoding: gzip`, and each
call's payload sized above `minGzipBodySize` so the fixed path still
gzips. Asserts `HTTP 200`, `Content-Encoding: gzip`, and that the
decoded batch contains all `n` responses with the expected ids/results —
not just reliance on `-race` to catch a regression. Before the fix,
running it with `-race` reliably reproduced both the data race and, on
some runs, the exact nil-pointer panic reported in the issue. After the
fix it passes cleanly and repeatably under `-race` (verified over 15
consecutive runs).
- Added `rpc/http_test.go` (`TestWithGzipStreamingHookPanicsOnNilHook`):
pins that `WithGzipStreamingHook` panics when given a nil hook.
- Added `rpc/handler_test.go` (`TestRunMethodFlushHookNilFunc`): pins
that `runMethod` does not panic when the hook stored on the context is a
typed nil `func()` rather than an untyped nil.
- Full `rpc/...` and `node/...` suites pass with `-race`.

### Manual end-to-end verification

Also reproduced the issue against two real running nodes, one built from
this branch's parent commit and one from this branch, both sent the
exact same JSON-RPC batch (16 calls to `debug_traceBlockByNumber`) with
`Accept-Encoding: gzip`:

- **Pre-fix binary**: crashed on the first request, with a panic
identical to the one reported in the issue (`flate.(*Writer).Flush` →
`gzip.(*Writer).Flush` → `gzipResponseWriter.Flush` → `runMethod` →
`handleCall` → `handleCallMsg` → `handleBatch`).
- **Fixed binary**: the same request succeeded (`HTTP 200`, correct JSON
body) across 8 consecutive attempts, node stayed up and kept producing
blocks throughout.

## Test plan

- [x] `go test -race -run TestGzipHandlerBatchConcurrentStreamableFlush
./node/...`
- [x] `go test -race -count=1 ./rpc/... ./node/...`
- [x] `make lint`
- [x] Manual repro against a real node: pre-fix binary crashes, fixed
binary doesn't

## Note

A pre-existing deadlock in `handleBatch` (`wg.Add(len(msgs))` vs.
`len(calls)` goroutines spawned) was flagged during review. It's
unrelated to the gzip race fixed here and will be addressed in a
separate PR.