[Notary] Improves Estimate of Response Size when Content-Length Absent

[Step7750]

Transfer encoding responses don't have a Content-Length header. Currently, we severely overshoot the body size since it counts the decompressed bytes.

Instead, this PR switches to more reliable methods such as the resource timing API and re-compressing with leeway.

Ref CSF-1322

---

Note

Medium Risk
Changes how max_recv_data is estimated for chunked/gzipped responses; underestimation could cause notary/prover protocol failures, while overestimation mainly wastes headroom.

Overview
Improves response size estimation in calculateResponseSize when Content-Length is missing by switching from blob.size (decompressed bytes) to a prioritized set of on-wire approximations.

When no Content-Length is present, it now consumes the body and estimates size via Resource Timing encodedBodySize (with padding), then re-gzipping via CompressionStream (with leeway) when the response was gzip-encoded, and finally falls back to decompressed byte length; adds helper functions getEncodedBodySizeFromPerformance and estimateGzipSize and updates docs/debug logs accordingly.

^{Reviewed by Cursor Bugbot for commit dfceef0. Bugbot is set up for automated code reviews on this repo. Configure here.}

[GODrums]

Complicated stuff, thanks for the comments!