Timestamp::clamp produces nanos == 1_000_000_000 for negative multiples of 1e9

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

In `src/wkt/src/timestamp.rs`, `Timestamp::clamp` normalizes nanoseconds when `nanos.cmp(&0_i32)` is `Ordering::Less`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/wkt/src/timestamp.rs#L180-L184

```rust
std::cmp::Ordering::Less => (
seconds.saturating_sub(1 - (nanos / Self::NS) as i64),
Self::NS + nanos % Self::NS,
),
```

When `nanos` is a negative multiple of `1_000_000_000` (such as `-1_000_000_000`), `nanos % Self::NS` is `0`. The formula evaluates to `Self::NS + 0 = 1_000_000_000`.

For example, `Timestamp::clamp(0, -1_000_000_000)` produces `{ seconds: -2, nanos: 1000000000 }`, violating the protobuf timestamp invariant that nanoseconds must be in `[0, 999_999_999]` and breaking `PartialOrd` comparison.

Start in src/wkt/src/timestamp.rs at Timestamp::clamp and reproduce the negative-multiple case described in the issue. Check the resulting seconds and nanoseconds against the protobuf invariant and PartialOrd behavior; done means negative normalization never produces nanos outside [0, 999,999,999].

Written by the indexing model from the issue text.