Instead of draining after every single registration or batching 5,
use a batch size of 3 which represents a realistic worst case where
multiple components schedule in the same loop iteration while staying
within the recycling pool (MAX_POOL_SIZE=5).
Scheduler registration benchmarks (SetTimeout, SetInterval, Defer) were
not calling scheduler.call() periodically to drain and clean up cancelled
items. In production, call() runs every loop iteration, keeping the
scheduler containers small. Without draining, cancelled items accumulated
causing O(n²) scan cost in cancel_item_locked_ that doesn't reflect
real-world behavior.
- SetTimeout: was only calling process_to_add() (no cleanup), now calls
call() every kKeyCount iterations
- SetInterval: was calling process_to_add() (no cleanup of items_), now
calls call() for proper cleanup
- Defer: was never draining the defer queue, now calls call() to process
deferred items as production does
- All three now advance time (++now) to match production loop behavior