* fix(s3api): cap copy-chunk receive buffer to avoid append-grow blowup
downloadChunkData accumulated the streamed chunk into a nil []byte via
`chunkData = append(chunkData, data...)`. ReadUrlAsStream pumps in 256 KiB
ticks, so a 64 MiB chunk grew the slice geometrically (256K → 512K →
1M → ... → 64M), allocating ~2x the chunk size for every transferred
byte. Combined with the 4-way per-request concurrency and any number of
in-flight UploadPartCopy calls (Harbor multipart assemble), this is what
produces the runaway-RSS pattern reported in #6541.
Pre-size the receive buffer to the known sizeInt so the callback fills
in place. Add a regression test that downloads a 16 MiB chunk through
httptest and asserts TotalAlloc stays under 1.5x the chunk size — the
pre-fix code allocates ~5x and trips the bound.
Local repro (weed 4.23, 6 parallel UploadPartCopy on a 512 MiB source):
before: baseline 96 MiB → peak 3124 MiB, never reclaimed
pprof: 650 MiB inuse in bytes.growSlice + 461 MiB in
downloadChunkData.func1
* test(s3api): assert downloaded chunk content matches payload
Address PR review feedback: the allocation-bound check alone would still
pass if a future regression silently truncated or corrupted the chunk.
Compare the returned bytes against the source payload (after the
TotalAlloc measurement window so bytes.Equal doesn't pollute it).
Chris Lu