api: support configurable batch size for keyspace Region scans

## Feature Request

### Describe your feature request related problem

PD exposes `GET /pd/api/v1/regions/keyspace/id/{id}` to list Regions belonging to a keyspace. Its `limit` parameter controls the total number of Regions returned, but there is no independent control over how many Regions PD scans and serializes at a time.

The current handler calls `ScanRegions` for the keyspace's RawKV and TxnKV ranges and then marshals the complete result into one buffer. When `limit=0`, both the scan and response construction are unbounded by a batch size. A keyspace containing many Regions can therefore cause a long Region-tree read-lock hold, a large temporary Region slice, and a large JSON buffer in PD.

Using a smaller positive `limit` avoids the large scan but truncates the result, so it cannot satisfy callers that need every Region. The missing capability is a server-side batch size for a full keyspace scan, independent of the existing result limit.

### Describe the feature you'd like

Extend the keyspace Region HTTP API with an optional batch-size control. For example:

```http
GET /pd/api/v1/regions/keyspace/id/{id}?limit=0&batch=1024
```

The two parameters should have separate meanings:

- `limit` remains the maximum total number of Regions returned by the request; `limit=0` continues to mean all Regions.
- `batch` limits the number of Regions processed by each internal scan and encode/write iteration.

This should remain one HTTP request with the existing response schema. It should not expose a page token, continuation parameter, or client-managed resume state.

The server should:

- preserve the existing behavior when `batch` is omitted;
- validate and cap `batch` to a safe range;
- scan the keyspace's RawKV and TxnKV ranges in bounded batches;
- keep the internal continuation key entirely on the server for the lifetime of the request;
- transition from the RawKV range to the TxnKV range without returning Regions outside the keyspace;
- incrementally encode and write one valid `RegionsInfo` JSON response instead of building the complete JSON payload in memory;
- stop promptly when the request context is canceled or the client disconnects;
- preserve the endpoint's existing externally visible consistency semantics, including under concurrent Region split and merge operations;
- return the same logical result as the current implementation for the same `limit` when the Region topology is stable.

Once the HTTP API supports this behavior, pd-ctl should expose the same control. For example:

```shell
pd-ctl region keyspace id 42 0 --batch 1024
```

The pd-ctl change should be a thin wrapper over the HTTP API rather than implementing keyspace range traversal or continuation logic on the client side.

### Describe alternatives you've considered

- `limit=0` returns all Regions today, but performs an unbounded scan and constructs the complete response in memory.
- A smaller positive `limit` bounds PD work but returns only the first part of the keyspace.
- A public page token would turn the operation into client-managed pagination and change the request's consistency model, which is not required for this use case.
- `pd-ctl region scan` already performs multiple bounded requests, but it scans the entire cluster rather than one keyspace.
- A pd-ctl-only implementation could traverse the generic Region range API, but that would duplicate RawKV/TxnKV range and continuation logic outside PD.

### Teachability, Documentation, Adoption, Migration Strategy

Document `batch` separately from `limit`, including that it controls server-side execution and does not change the number or schema of results returned.

Document the derived pd-ctl usage:

```shell
pd-ctl region keyspace id 42 0 --batch 1024 > regions.json
```

Add API and pd-ctl tests covering omitted and invalid batch sizes, multiple internal batches, combinations of `limit` and `batch`, RawKV and TxnKV ranges, the transition between ranges, exact keyspace boundaries, the maximum keyspace ID, request cancellation, concurrent split and merge behavior, and equality with the current response for a stable Region topology.

Add a large-keyspace benchmark or stress test demonstrating bounded per-batch lock hold time and memory usage.

The API extension and pd-ctl flag should be additive and require no migration.

Start at the handler for GET /pd/api/v1/regions/keyspace/id/{id} and the pd-ctl `region keyspace id` command, then trace the existing ScanRegions calls and response construction. Review the API and pd-ctl tests around these entry points. Done means batch is validated and applied server-side without changing the response schema, while preserving stable-topology results and cancellation behavior.

Written by the indexing model from the issue text.