sql: deflake TestStreamerTightBudget by fixing the streamer's initial estimate

[ZhouXing19]

TestStreamerTightBudget gives the Streamer a budget so tight that a
single 1 MiB result puts it in debt, and asserts that peak memory usage
stays around the expected ~2 MiB. The assertion flaked, observing usage
as high as 4.6 MiB.

The cause is the Streamer's cold initial response-size estimate. With no
stats on the test table, the Streamer starts from its 1 KiB default
estimate and issues all five lookup requests eagerly on the first pass.
Eager (non-head-of-line) requests are sent with AllowEmpty=true, so
when a 1 MiB blob exceeds the tiny TargetBytes the KV layer returns an
empty response with a resume span, and the Streamer re-issues it. For
five rows this produces nine KV gRPC calls (five eager + four resumes)
rather than five — matching the "KV gRPC calls: 9" in the failure. During
that eager/resume churn, multiple full responses can transiently be held
at once under unfavorable goroutine scheduling, pushing peak memory well
above 2 MiB and tripping the assertion.

This gives the Streamer an accurate initial estimate (the blob size) via
the sql.distsql.streamer.initial_avg_response_size cluster setting. The
first head-of-line request then exhausts the budget on its own, so no
eager requests are issued and the Streamer deterministically keeps a
single request in progress (five KV gRPC calls, no resumes) — exactly the
behavior this test means to verify. In production this estimate is
supplied by optimizer stats.

Verified with 300 stress runs; measured usage is a stable 2.1 MiB.

Fixes: #170853
Epic: none
Release note: None

🤖 Generated with Claude Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[cockroach-teamcity]

This change is