DOC-6996 Document the go-redis pipeline connection pool - #3854

Add a Connection pooling section to the go-redis production usage page
covering the dedicated pipeline pool that go-redis PR #3959 makes
default-on, and point the two pipeline pages at it.

The ticket framed this as expanding the autopipeline paragraph at lines
157-160. That turned out to be the wrong home. Pipeline() and
TxPipeline() both route through withPipelineConn (redis.go:1753-1765,
1807), so the new pool serves hand-built pipelines and MULTI/EXEC too,
not just automatic pipelining -- and autopipeline.md carries an
"experimental feature" banner that would have wrongly colored
default-on pooling behavior. produsage.md already owns Timeouts and
Retries, so sizing advice belongs there; the Go guide had no pooling
prose at all before this.

The ticket's "Not parked: the change is already merged upstream" is a
merged-vs-released conflation. v9.22.0 shipped 2026-08-03, #3959 merged
2026-08-24, master is 15 commits ahead of the tag and no release
contains it. Ran the negative check to be sure rather than reasoning
from dates: on v9.22.0, PoolStats().PipelineStats is nil by default AND
stays nil with PipelinePoolSize:10 alone, because the released version
only builds the pool when a buffer field is set. So the whole section
describes behavior no reader can observe yet, and the version line is a
deliberate vX.Y.Z placeholder with an HTML TODO.

Compiling the PipelineStats snippet was necessary but not sufficient.
Running it against master + Redis 8.8 is what confirmed the claims:
pipeline pool non-nil and holding zero connections when idle, a plain
command touching only the main pool, both Pipeline() and TxPipeline()
using the pipeline pool, PipelinePoolSize:-1 making PipelineStats nil,
and 60 concurrent pipelines capping the pool at 10. The fallback claim
did NOT reproduce on that burst (Timeouts stayed 0, main pool
untouched) -- fast batches never hold a connection past the 100ms wait.
It took PipelinePoolSize:1 plus BLPOP batches to force it: Timeouts=5
and five batches on the main pool. DEBUG SLEEP is unavailable on the
local server, so BLPOP on a never-populated key is the way to hold a
pipeline connection open.

Also fixed a pre-existing broken anchor in the same checklist:
#seamless-client-experience never matched the "Smart client handoffs"
heading.

Deliberately not done: no connect.md change for client-side caching.
Pipeline connections now skip CLIENT TRACKING (redis.go:942-949), but
pipelined commands never consulted or populated the cache in v9.22.0
either, so nothing a reader can observe changed. URL query params
deferred by decision -- documenting them drags in ParseURL coverage the
Go guide has never had.

Upstream doc bug worth reporting: osscluster.go:148 still says the pool
is created "only when PipelineReadBufferSize or PipelineWriteBufferSize
is set", stale after #3959 and contradicting ring.go:154. Cluster nodes
are built via clOpt.NewClient() (osscluster.go:518) with
PipelinePoolSize passed through, so they do get pipeline pools -- which
is also why the ceiling arithmetic multiplies per node.

Learned: merged != released, and a saturation claim needs saturation forced -- a 60-pipeline burst never triggered the main-pool fallback that PipelinePoolSize:1 plus BLPOP did.
Constraint: the PipelineStats snippet must keep `if ps := stats.PipelineStats; ps != nil` -- the field is *internal/pool.Stats, so type inference is the only form that compiles outside the module, not a style preference.
Constraint: produsage.md carries no page-level bannerText; the pipeline pool's version requirement is stated in-section so the released Health checks, Retries and Timeouts sections are not mislabeled as unreleased.
Rejected: expanding autopipeline.md lines 157-160 as the ticket suggested | files default-on pooling under that page's experimental-feature banner and leaves hand-built Pipeline()/TxPipeline() readers with nothing
Gaps: the 64 KiB buffer defaults and the RESP3 minimum clamp are read from pipelinePoolOptions, not observed at runtime; the Limiter-charged-once behavior is likewise source-only.
Recheck: replace the vX.Y.Z placeholder and delete the DOC-6996 HTML comment in produsage.md when a non-prerelease go-redis tag contains bd0cea4.
Directive: verify DefaultPipelinePoolSize (10), DefaultPipelineBufferSize (64 KiB) and DefaultPipelinePoolTimeout (100ms) against the shipping tag before merging -- all three are quoted as bare numbers in the prose and table.
Ticket: DOC-6996
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>