Tokio Gives Progress, Not Ordering: Scheduling 1M Tasks

I assumed early event tasks would finish first, but our logs showed significant drift when spawning 1 million Tokio tasks. The runtime prioritizes progress over strict ordering, causing earlier tasks to wait while newer ones run. By adding a Semaphore to bound concurrent events, we maintained throughput while drastically reducing peak memory usage.