Vespa CLI: 在压缩请求超时或收到早期响应时,`vespa feed` 在 resultWithResponse 中发生崩溃

Describe the bug vespa feed panics inside document.(*Client).resultWithResponse when a compressed request either exceeds the client timeout or gets a response before its body has been fully written. The panic takes the whole feed process down, so the client's own retry/backoff never runs for that operation and every in-flight document is lost. From reading client/go/internal/vespa/document/http.go at master 3026877: when the body is gzip-compressed (default --compression auto for bodies > 512 B, i.e. most updates) the request body passed to http.NewRequest is the pooled *bytes.Buffer itself. Send returns that buffer to the sync.Pool with a defer as soon as Do returns. If Do returns while http.Transport's write loop is still copying the request body, that goroutine keeps advancing the buffer's read offset while preparePending re-fills the same buffer for the next document and resultWithResponse does buf.Reset(); io.Copy(buf, resp.Body). Once off > len(buf), make([]byte, buf.Len()) panics with makeslice: len out of range and buf.Bytes() panics with slice bounds out of range. Uncompressed bodies go through bytes.NewReader(body) and are not affected, which matches what we see: our small-put feeder never crashed, the update feeder did.