[Bug] PD task REST: balanceLeaders throws a bare HTTP 500 during the balance-shard window, and task responses cannot be told apart from a no-op or a follower answer

[bitflicker64]

Bug Type (问题类型)

rest-api (结果不合预期)

Before submit

• I have confirmed and searched that there are no similar problems in the historical issue and documents

Environment (环境信息)

• Server Version: master 83ef9f3 (pd image sha256:69dc1d4e8625)
• Backend: HStore, 3 PD + 3 Store, 12 shard groups
• OS: kind v0.33 (Kubernetes 1.37.0)

Expected & Actual behavior (期望与实际表现)

Measured 2026-09-22 while executing the documented recovery sequence (patrolPartitions, balanceLeaders, balancePartitions) on the PD leader with a follower as control:

1. GET /v1/task/balanceLeaders within 180 s of a balancePartitions call (which sets the balance-shard key even when it moves nothing) answers {"timestamp":...,"status":500,"error":"Internal Server Error","path":"/v1/task/balanceLeaders"} with no reason. The reason (PDException: balance shard is processing, please try later!, TaskScheduleService.java:478) appears only in the PD log. Cause: TaskAPI.balanceLeaders (TaskAPI.java:92-95) declares throws PDException with no handler, while its siblings catch and return toJSON(e). One-line fix.
2. GET /v1/task/patrolPartitions returns the byte-identical body {"status": 0,"partitions": [ ]} on the leader and on a follower, whether or not it repaired anything; a follower does no work and reports success. balancePartitions differs by two bytes ({} from the leader, empty body from a follower). Operators driving recovery over REST cannot tell "ran and repaired", "ran, nothing to do" and "hit a follower, did nothing" apart without reading PD logs.

Ask: catch the PDException in balanceLeaders like the sibling endpoints; and have the task endpoints either redirect to the leader (as the read APIs do via getMembers) or answer an explicit error naming the leader, plus include what was done (groups reallocated, leaders moved, partitions moved) in the body.

[bitflicker64]

Part 1 landed as #3233, and the chart README in #3218 already documents the new refusal body. For part 2 the chart's Disaster Recovery section carries the workaround: telling a real run from a no-op or a follower answer via the PD leader's log (reallocShards, shardOffline) and /v1/shardGroups diffs. When part 2 merges: if #3218 has merged, add a chart TODO to simplify that passage; else comment there to update and re-test.