Dasher Pay with Store Waits and Peak Hours

A Dasher earns $0.30 per minute for each active delivery. A delivery becomes active when it is accepted and stops being active when it is fulfilled. Therefore, ordinary concurrent-delivery time is paid at activeDeliveries * $0.30 per minute.
Each string in events has the form HH:MM EVENT orderId, where EVENT is ACCEPT, ARRIVE, PICKUP, or FULFILL. Events are in strictly increasing time order and describe valid order lifecycles.
An ARRIVE event begins a store-wait interval for that order, and its matching PICKUP ends the interval. While the Dasher is waiting at a store, only the order being waited on contributes pay; other active orders do not contribute during that interval. Outside a store wait, every active order contributes normally.
Each string in peakHours has the form start end. A peak window is half-open: it includes start and excludes end. Pay earned during a peak window is doubled. Peak windows do not overlap.
Return the total pay in dollars after processing all events.

Function
calculateDasherPay(events: String[], peakHours: String[]) → double

Examples
Example 1
events = ["06:15 ACCEPT A","06:18 ACCEPT B","06:36 FULFILL A","06:45 FULFILL B"]
peakHours = []
return = 14.4
Pay is 3 * 0.30 = 0.90, then 18 * 0.60 = 10.80 while two deliveries overlap, then 9 * 0.30 = 2.70. The total is $14.40.
Example 2
events = ["06:15 ACCEPT A","06:18 ACCEPT B","06:19 ARRIVE A","06:22 PICKUP A","06:30 ARRIVE B","06:33 PICKUP B","06:36 FULFILL A","06:45 FULFILL B"]
peakHours = []
return = 12.6
During 06:19-06:22 only order A contributes, and during 06:30-06:33 only order B contributes. All other intervals use the number of active deliveries, giving $12.60.
Example 3
events = ["06:15 ACCEPT A","06:18 ACCEPT B","06:19 ARRIVE A","06:22 PICKUP A","06:30 ARRIVE B","06:33 PICKUP B","06:36 FULFILL A","06:45 FULFILL B"]
peakHours = ["06:20 06:30"]
return = 18.0
The ordinary total is $12.60. The base pay earned from 06:20 through 06:30 is $5.40, and peak time pays that amount once more, for $18.00.

Constraints
2 <= events.length <= 1000
0 <= peakHours.length <= 100
All times use valid same-day 24-hour HH:MM notation.
Events are in strictly increasing timestamp order.
Every order has one ACCEPT before its optional ARRIVE and PICKUP pair and one later FULFILL.
All accepted orders are fulfilled by the final event.
At most one store-wait interval is active at a time.
Peak windows are valid, half-open, and non-overlapping.

Convert every HH:MM to minutes since midnight. Walk the events in order, keeping a count of active orders and a nullable waitingOrder. Between event i and event i+1, the rate is 0.30 if someone is waiting (only that order pays), otherwise active * 0.30. Add rate * duration. For peak, compute the overlap of [prev, cur) with each peak window as max(0, min(cur, end) - max(prev, start)) and add rate * overlap once more. Peak windows don't overlap, so summing is safe. Pitfalls: updating state before computing the segment instead of after, forgetting that a wait only pays one order, and floating point drift. Work in cents or multiply by 30 as integers, then divide at the end. With at most 1000 events and 100 windows, brute force is fine. StealthCoder is the hedge if the live OA rattles you on the overlap formula.

StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.