server: check target PD readiness before leader transfer

## Enhancement Task

PD currently supports `/pd/api/v2/ready` to indicate whether a PD member has finished the initial region loading process and is ready for leader promotion. However, some PD leader transfer paths may still transfer embedded etcd leadership to a target PD before that target has finished loading regions.

This can make a not-yet-ready PD become the PD leader, which may affect leader promotion behavior after restart or during recovery-sensitive operations.

Enhance PD leader transfer logic to check the target PD readiness before selected leader transfer paths call `MoveEtcdLeader`.

Scope:

- Add an opt-in target readiness check for `MoveEtcdLeader`.
- Apply the check to manual leader transfer APIs:
- `/pd/api/v1/leader/transfer/{next_leader}`
- `/pd/api/v1/leader/resign`
- Apply the check to automatic leader transfer by leader priority.
- Do not apply the check to recovery or fallback paths such as PD leader lost recovery and frequent campaign protection.
- Before calling `/pd/api/v2/ready`, request the target PD `/pd/api/v1/version`.
- If the target PD version does not support `/ready`, treat the target as ready after the version request succeeds for compatibility.
- Keep existing management API behavior unchanged. Do not add a force option or change request/response formats.

Expected behavior:

- Manual transfer to an unready target PD should fail before moving etcd leadership.
- Manual resign should skip unready candidates and choose a ready candidate when available.
- Manual resign should fail if no ready candidate exists.
- Priority-based leader transfer should skip the current round when the higher-priority target is not ready.
- Recovery paths should keep the existing behavior and should not be blocked by readiness checks.

Trace the existing leader transfer paths for MoveEtcdLeader, including the manual transfer and resign APIs and automatic priority-based transfer. Start by reviewing how the target /pd/api/v1/version and /pd/api/v2/ready endpoints are used, then verify that readiness blocks only the selected paths while recovery and fallback paths remain unchanged. Done means the listed manual and priority behaviors occur without changing management API formats.

Written by the indexing model from the issue text.