Support the store txn protocol version range reported by TiKV

## Development Task

PD needs to maintain the transaction protocol version range of each store so that it can be returned to clients and kept in the store metadata caches of the router and scheduling microservices, which watch the store metadata from etcd and serve queries from their own caches.

TiKV reports the range it currently accepts through `PutStore` (field `metapb.Store.txn_protocol_version_range`, added by [pingcap/kvproto#1534](https://github.com/pingcap/kvproto/pull/1534)). PD should treat the range as opaque metadata of the store: the value follows the last successful `PutStore` registration, and PD must not derive it from `Store.version`, from labels, or from any protocol constant known by PD.

## Scope

- Accept the range both on the first registration of a new store and on the update of an existing store.
- Replace the previous range as a whole: a reported range is copied and may lower the previous upper bound to reflect a rollback, while a missing range clears the stored value. An explicit `[0, 0]` must stay distinguishable from a missing range.
- Store the reported values as is: no `min > max` rejection, no normalization, and no automatic fill of a missing range with `[0, 0]`. An abnormal range is kept for identification and troubleshooting, and the fail-closed decision belongs to the consumer.
- Keep the field in the store metadata caches of the router and the scheduling microservices when an already loaded store is updated.
- Return the field from `GetStore` and `GetAllStores`, and restore it after a PD restart, without introducing a separate storage key, a schema migration, or an independent range cache.
- Upgrade the kvproto dependency of every module, including `client/`, `tools/` and `tests/integrations/`, so that the field is available wherever PD source is built.

## Out of Scope

- Transaction RPC admission of a protocol version, and shared-lock runtime defenses.
- Version negotiation RPCs, feature gates, scheduling limits, and caller authorization.
- Client-side version selection and error handling, which belong to the related client implementations.

## Acceptance Criteria

- A new store registered through `PutStore` reports the same range through the PD cache, `GetStore` and `GetAllStores`, for a missing range, an explicit `[0, 0]` and a non-zero range.
- An existing store follows the range of the last successful `PutStore` while its binary version and other fields stay unchanged, including an idempotent re-registration, a lowered upper bound, and a non-nil to nil transition.
- The range survives an update or a deletion of labels, and remains the same after a PD restart with its data directory kept.
- The router store watcher keeps the range of an already loaded store up to date, and the query helpers it uses return the update.

Start at the PutStore entry point and trace store metadata through GetStore and GetAllStores, persistence across restart, and the router store watcher. Check how the client/, tools/, and tests/integrations/ modules consume kvproto. Done means the opaque range follows registration, survives updates and restart, is returned by the APIs, and reaches already loaded router stores.

Written by the indexing model from the issue text.