ZScheduler Parks/Unparks Workers Too Frequently - State-Based Batching

This PR addresses issue #9878 by optimizing the maybeUnparkWorker mechanism in ZScheduler to reduce excessive park/unpark cycles.

Problem

The scheduler was calling LockSupport.unpark too frequently in the hotpath, causing performance degradation. Each call involves expensive CAS operations and thread signaling.

Solution

Implemented a state-based batching mechanism in maybeUnparkWorker:

• Track worker state changes using bitmasked counters
• Batch unpark operations when multiple workers become available
• Reduce redundant LockSupport.unpark calls by coalescing requests

Changes

• Modified ZScheduler.scala to add batching logic in maybeUnparkWorker
• Preserved all existing semantics and thread safety guarantees
• Optimized for the common case where multiple workers are available

Performance Impact

• Reduces park/unpark call frequency significantly
• Maintains fairness and responsiveness under varying loads
• Addresses the excessive cycling mentioned in #9878

Fixes #9878

/claim #9878