There is a possible overflow in TSODispatcher

## Bug Report

### What did you do?

The request count in pd/pkg/utils/tsoutil/tso_dispatcher.go (processRequests) is accumulated in a uint32, which could lead to overflow in extreme cases or be triggered by a malicious client.

```go
func (s *TSODispatcher) processRequests(forwardStream stream, requests []Request) error {
// Merge the requests
count := uint32(0)
for _, request := range requests {
count += request.getCount()
}

start := time.Now()
resp, err := requests[0].process(forwardStream, count)
if err != nil {
return err
}
s.tsoProxyHandleDuration.Observe(time.Since(start).Seconds())
if s.tsoProxyBatchSize != nil {
s.tsoProxyBatchSize.Observe(float64(count))
}
// Split the response
ts := resp.GetTimestamp()
physical, logical := ts.GetPhysical(), ts.GetLogical()
// `logical` is the largest ts's logical part here, we need to do the subtracting before we finish each TSO request.
// This is different from the logic of client batch, for example, if we have a largest ts whose logical part is 10,
// count is 5, then the splitting results should be 5 and 10.
firstLogical := logical - int64(count)
return s.finishRequest(requests, physical, firstLogical)
}
```

### What did you expect to see?
- Merged count should not silently overflow.
- If total count exceeds uint32, dispatcher should return an error (or use wider type with explicit bound check).
- Proxy split logic should always match the exact number of timestamps requested upstream.

### What did you see instead?
- count overflows silently due to uint32 wraparound.
- Upstream process(...) is called with a wrapped (smaller) count.
- Then finishRequest(...) still splits using original per-request counts, causing allocation/splitting mismatch.
- tsoProxyBatchSize metric is also incorrect when overflow happens.

### What version of PD are you using (`pd-server -V`)?
master branch