http.request.resend_count metric attribute subtracts 1 from 0-based attempt count

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

In `src/gax-internal/src/observability/client_signals/transport_metric.rs`, the `http.request.resend_count` OpenTelemetry metric attribute is recorded with:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/gax-internal/src/observability/client_signals/transport_metric.rs#L118-L120

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/gax-internal/src/observability/client_signals/transport_metric.rs#L172-L175

```rust
Some((attempt_count.saturating_sub(1) as i64).into())
```

However, the calling retry loops in `http.rs` and `grpc_helpers.rs` pass an `attempt_count` that is already a 0-based prior-attempt count (`0` on initial request, `1` on first retry):

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/gax-internal/src/http.rs#L391-L403

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/gax-internal/src/http.rs#L488-L494

Because `saturating_sub(1)` is applied to an already 0-based counter, both the initial request and the first retry record `resend_count = 0`. The attempt span in `http_tracing.rs:72-76` treats the value as 0-based, causing the span attribute and metric attribute to disagree.

Read the cited sections of src/gax-internal/src/observability/client_signals/transport_metric.rs, then compare the attempt_count passed from http.rs and grpc_helpers.rs with the 0-based value used in http_tracing.rs. Verify the initial request and first retry produce consistent resend_count attributes; done means the metric and span interpretations agree.

Written by the indexing model from the issue text.