Supervisor marks succeeded replicas as failed too aggressively

### Affected Version

All versions since 0.9.1.

### Description

The `seekableSupervisor` does the below when a replica is succeeded.

- Check the status of all other replicas from `taskStorage`.
- Stop all replicas if they are not finished yet.
- For the tasks of unknown status, the supervisor kills them.
- If the stop request fails for some tasks, the supervisor kills them.

However, there's some race in this algorithm because task status is not updated in real time. Instead, the supervisor updates it per `runNotice`. As a result, the supervisor can kill some already finished tasks successfully if their status is not updated yet. This would lead to mark them as failed even though they are finished as succeeded in the task logs, which seems very confused.

One way to workaround this problem is to check task status more eagerly. However, this would just mitigate this issue happening less. I think we eventually need the following changes in the future.

- Updating task status immediately when the status change is notified to the overlord.
- Add a new task status for canceled tasks.

I'm seeing this problem happening very frequently in our cluster and so marking as a release blocker fo 0.15.0.

Start by tracing the seekableSupervisor flow that checks taskStorage after a replica succeeds, and follow how runNotice updates task status. Reproduce the race in which finished replicas are killed before their status is visible, then define completion as preserving succeeded replicas rather than marking them failed; the issue does not name a source file or test.

Written by the indexing model from the issue text.