fix(storage): clamp resume offsets in the gRPC write path - #20530

Problem

When a resumable gRPC write is retried, the sender reconnects and injects a
completion carrying the persisted size returned by QueryWriteStatus. That
figure counts bytes durably written by the earlier, aborted attempt, so
w.bufBaseOffset can advance past everything the current attempt has sent.

Two indices derived from it were used unchecked to reslice buffers in
(*gRPCWriterCommandWrite).handle:

toCopyIn := cmdBuf[int(w.bufBaseOffset-offset):]
w.bufUnsentIdx = int(sentOffset - w.bufBaseOffset)

The first panics once the persisted offset passes the end of the command
buffer:

panic: runtime error: slice bounds out of range [2097152:608579]
  grpc_writer.go  (*gRPCWriterCommandWrite).handle

The second can go negative, which panics on the next reslice of w.buf.

Both are runtime panics, so they take down the calling process rather than
failing the upload.

Why this has not been reported

The resume path is hard to reach today. Plain gRPC uploads are non-idempotent,
so run() gives them zero retries, and an attempt that hangs never ends. It
does become reachable for uploads that are idempotent — IfGenerationMatch,
DoesNotExist, or an appendable takeover — where a transient mid-upload error
triggers a genuine retry of a multi-chunk write.

Fix

Clamp both indices to their slice bounds. A skip past the end of cmdBuf means
the service already holds all of it, so there is nothing left to stage and the
next write resumes from the offset the service reported — nothing is dropped
and nothing is re-sent.

writeLoopAttempt already clamps the same index for the same reason, with a
comment noting that a completion can land beyond all of w.buf; this applies
that treatment to the two sites in the command handler that lacked it.

The change only ever narrows a slice range. It cannot widen one, reorder sends,
or alter bufBaseOffset / flushOffset. In any state where the clamps do not
engage, behaviour is unchanged; where they do, the previous behaviour was a
panic.

Tests

TestGRPCWriter_ServiceAcksBeyondSentBytes drives writeLoop with a sender
that reports a persisted offset two chunks beyond what was sent, which is what
mockSender's new overAckAfter / overAckBy fields model. Both default to
zero, so existing tests are unaffected.

The test asserts more than survival. The payload is a position-dependent
pattern, and every buffer the sender receives must carry exactly the payload
bytes belonging at the offset it was sent to, with no region sent twice —
a clamp that shifted the stream would be silent object corruption, which is
worse than the panic. Reverting the fix reproduces the panic:

clamps reverted → panic: runtime error: slice bounds out of range [786432:262144]
restored        → ok  cloud.google.com/go/storage

Verified:

• go test -short -race ./... across the storage module — pass
• New test under -race -count=5 — pass
• 50 *Emulated tests against the storage-testbench at main — pass
  (TestWriterRetryAttrsEmulated and TestRetryNeverEmulated fail in my local
  environment, but they fail identically on a clean checkout and one of them is
  the HTTP subtest, so they are unrelated to this change)