docs: clarify pool return timing for queryValues in executeQuery/executeBatch

Update comments to accurately describe the trade-off: pooled
queryValues slices are returned after c.exec() completes (full
round-trip) rather than immediately after frame serialization.
Document that this is intentional — holding slices slightly longer
keeps the code simpler and avoids error-prone refactoring of the
synchronous c.exec() call.

Author: mykaul

conn.go

@@ -1572,7 +1572,8 @@ func (c *Conn) executeQuery(ctx context.Context, qry *Query) (iter *Iter) {
 	}
 
 	framer, err := c.exec(ctx, frame, qry.trace, qry.GetRequestTimeout())
-	// Return pooled queryValues; values were consumed during frame serialization inside c.exec().
+	// Return pooled values; consumed by buildFrame at the start of c.exec().
+	// Returned after round-trip (not right after serialization) for simplicity.
 	putQueryValues(params.values)
 	if err != nil {
 		return &Iter{err: err}
@@ -1796,7 +1797,8 @@ func (c *Conn) executeBatch(ctx context.Context, batch *Batch) (iter *Iter) {
 
 	// TODO: should batch support tracing?
 	framer, err := c.exec(batch.Context(), req, batch.trace, batch.GetRequestTimeout())
-	// Return pooled queryValues; values were consumed during frame serialization inside c.exec().
+	// Return pooled values; consumed by buildFrame at the start of c.exec().
+	// Returned after round-trip (not right after serialization) for simplicity.
 	putBatchQueryValues(req.statements)
 	if err != nil {
 		return &Iter{err: err}