节流窗口合规回放：最少需撤单次数

实现 solution(times: list[float], W: float, K: int) -> int。一台订单路由器在（已按升序排列的）时间戳 times（单位：秒）向某交易场所发出订单。该场所启用节流：任意一个闭的 W 秒滚动窗口内，存活的订单数最多为 K。返回最少需要撤掉的订单数，使得在剩余时间戳上，每个 W 秒滚动窗口内的存活订单都不超过 K。

输入为空时返回 0；若整段时间戳本身就满足节流约束（每个 W 秒窗口都不超过 K），同样返回 0。窗口两端均为闭区间：位于"窗口起点 + W"位置处的时间戳仍然算在该窗口内。等值时间戳视为同一时刻并发，全部计入同一窗口。

例：solution([0.0, 1.0, 2.0, 3.0], 2.0, 2) 返回 1。以 0.0 为起点的前向窗口 [0.0, 2.0] 内有三个时间戳，需要撤掉一笔；贪心撤掉 times[2] = 2.0（违规窗口内最晚的那一笔），剩下 {0.0, 1.0, 3.0} 在所有闭 2 秒窗口内的存活数都不超过 2。

朴素的 O(N^2) 解法（对每个起点重新数一次窗口）在较大的隐藏用例上会超时；预期解法是一次自左向右的双指针线性扫描：每来一笔新订单，先剔除掉时间落在 [t - W, t] 区间外的存活订单，然后判断如果把这笔加入是否会让窗口内的存活数超过 K——超过则撤掉这一笔。这一贪心可证为最优：撤违规窗口内"最晚"的那一笔不会让任何更早的窗口变差，且最大化缓解了后续窗口。

实现细节由 stubs/stub.py 提供。

实践背景

交易场所的合规网关通常会对单客户端在滚动时间窗内的活跃订单数设上限——这是对失控循环、参数误填、热路径压测等场景的一道粗粒度防线，避免把撮合引擎打挂。运维或合规团队在做事后回放（成交对账、节流参数 what-if、下一次上线前的调参）时，"为了严格满足节流约束，至少要撤掉多少笔？"这个问题既给出了监管视角下的最差情形，也给出了节流真上线后吞吐损耗的一个上界。贪心"撤违规窗口内最晚的一笔"恰好就是大多数场所线上跑的实时节流逻辑，所以离线回放出来的数和线上实际被拦截的笔数应当吻合（前提是上线参数与回放参数一致）。