Implement an event-timeout detector for a job scheduler. You are given a global timeout `T` and a sequence of API calls. Each event has: - `event_id` (integer) - `type` in `{start, ping, end}` - `timestamp` (integer) An event is considered active after a `start` and remains active until a valid `end` is processed. Timeout rule: - An active event is timed out at time `now_ts` if `now_ts - last_updated_ts > T`. - `ping` updates `last_updated_ts`. - `end` removes the event from consideration. - A timed-out event stays timed out until it receives a newer `start`/`ping` or a valid `end`. Because this platform expects a single function, implement `solution(T, operations)` where: - `("process", event_id, type, timestamp)` means call `process(event)` - `("get", now_ts)` means call `get_timed_out(now_ts)` Return the result of every `get` call. Required behavior for tricky cases: - `ping` or `end` without a prior active `start`: ignore. - Duplicate or stale `start`/`ping` with `timestamp <=` the event's latest accepted timestamp: ignore. - A valid `end` for an active event is accepted only if `end.timestamp >= last_updated_ts`; otherwise it is stale and ignored. - Multiple `start` events: if the new `start` has a strictly larger timestamp, treat it as a restart/reset. - A new `start` after an `end` is allowed only if its timestamp is strictly larger than the last accepted timestamp for that event. - Zero or negative timeouts use the same strict rule `now_ts - last_updated_ts > T`. For deterministic output, each `get` must return currently timed-out `event_id`s in the order they became timed out; if multiple events become timed out on the same `get`, smaller `event_id` comes first.