Violation of ordering key pause on batch send failure in SequentialBatchActor

Unconfirmed. This is the result of a search with Gemini, may be a false positive.

In `SequentialBatchActor::flush`, the loop drains `self.pending_msgs` into `batch` via `self.move_to_batch_and_flush()` and awaits in-flight batch completion via `self.handle_inflight_join(inflight.join_next().await)`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/pubsub/src/publisher/actor.rs#L482-L497

If an in-flight batch send fails, `handle_inflight_join` invokes `self.pause()`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/pubsub/src/publisher/actor.rs#L533-L541

`self.pause()` sets `self.paused = true` and fails remaining messages in `self.pending_msgs` with `PublishError::OrderingKeyPaused`. However, `self.pause()` does not clear or fail messages already buffered in `batch`.

After `pending_msgs` is drained, lines 489–495 execute:
```rust
if !batch.is_empty() {
batch.flush(
self.context.client.clone(),
self.context.topic.clone(),
inflight,
);
}
```
Because `flush()` does not check `self.paused` and `batch` was not cleared by `self.pause()`, `batch.flush(...)` proceeds to send the buffered messages to Pub/Sub over the network. This violates the ordering key guarantee: subsequent messages for an ordering key must not be published after a preceding batch failure while the key is paused.

Start in src/pubsub/src/publisher/actor.rs at SequentialBatchActor::flush, then read handle_inflight_join and pause. Trace how an in-flight failure changes paused state while messages remain in batch. Done means buffered messages for a paused ordering key are not sent after the preceding batch fails.

Written by the indexing model from the issue text.