Canceled contexts can still consume work in select-based paths

## Bug Report

### What did you do?

While reviewing internal select-based cancellation paths, I found several places where `ctx.Done()` is selected together with another ready channel that consumes work or acquires resources.

Affected examples include:

- `OrderedSingleFlight.Do`
- client batch request collection
- concurrency limiter token acquisition
- deadline watcher registration
- service discovery singleflight calls
- router/resource-manager dispatcher cancellation paths

### What did you expect to see?

When the context is already canceled, these paths should return the context error before consuming requests, acquiring tokens, registering deadlines, or starting shared work. If cancellation happens after resources are acquired, the resources or collected requests should be cleaned up before returning.

### What did you see instead?

Some paths may still consume a request, acquire a token, register a deadline, or start shared work when cancellation races with another ready select case.

In particular:

- an already canceled `OrderedSingleFlight.Do` call may start an execution
- `ConcurrencyLimiter.AcquireToken` may return a token for a canceled context
- `ConcurrentRunner.run` may return before releasing a token
- batch collection may collect requests after cancellation
- router dispatcher may exit after collecting requests without finishing them

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

Current master.

Start by tracing the listed entry points: OrderedSingleFlight.Do, ConcurrencyLimiter.AcquireToken, ConcurrentRunner.run, client batch collection, deadline watcher registration, service discovery singleflight, and the router/resource-manager dispatcher. Identify the relevant cancellation tests or package tests, then verify that canceled calls do not consume work or resources and that acquired resources and collected requests are cleaned up before returning.

Written by the indexing model from the issue text.