unsafe recovery should cancel existing scheduling operators

## Bug Report

### What did you do?

Start online unsafe recovery while PD may still have existing scheduling operators.

Code inspection shows that unsafe recovery enters the `CollectReport` stage with a TODO to clean up existing operators, but it currently only halts new scheduling. Existing running operators, waiting operators, and pending operator notifications can remain in the operator controller.

### What did you expect to see?

When online unsafe recovery starts collecting store reports, PD should cancel existing scheduling operators and clear pending operator notifications, so recovery planning is based on a stable state and stale scheduling commands do not keep interfering with recovery.

### What did you see instead?

Existing operators are not explicitly cleaned up when unsafe recovery enters `CollectReport`.

This can allow old scheduling operators to continue dispatching or later be promoted from the waiting queue during unsafe recovery. It is more likely a recovery liveness or determinism problem than a direct TiKV metadata correctness issue, but it can interfere with unsafe recovery progress.

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

master