Investigate optimizing StormService scale-down to avoid PDB violations under concurrent disruptions

### 🚀 Feature Description and Motivation

In our GPU inference workloads, we use StormService (which manages RoleSets and Pods) alongside PodDisruptionBudget (PDB) to maintain service availability during disruptions.

However, we’ve observed that during concurrent scale-downs or evictions, PDB protections can become ineffective, leading to more Pods being disrupted than intended.

This usually happens in scenarios like:

- Rolling updates of StormService
- Node maintenance
- Cluster scale-in operations
- Or node-level resource pressure triggering evictions

If we rely purely on Kubernetes PDB, the scheduler tends to serialize Pod evictions, severely impacting efficiency (e.g. in multi-node upgrades, it becomes unacceptably slow).
If we allow concurrent evictions, we risk violating the PDB constraints, reducing availability.

### Use Case

make sure the storm service have great operation experiences even with PDB

### Proposed Solution

_No response_

The issue names no files, tests, or entry points beyond StormService, RoleSets, Pods, and Kubernetes PDBs. Start by tracing how concurrent scale-down and eviction decisions are coordinated; done means a concrete, validated approach that preserves PDB availability without serializing all disruptions.

Written by the indexing model from the issue text.