报价引擎活跃集合：并发活跃报价的峰值数量

实现 solution(events: list[list[str]]) -> int。某做市报价服务按到达顺序发出报价生命周期事件流 events，每条事件是 [quote_id, action]，其中 action 为 "ADD"（让该 quote_id 进入活跃集合）或 "REMOVE"（让该 quote_id 离开活跃集合；若该 id 当前并不活跃，则视为 no-op）。返回时间线上同时活跃的 quote_id 数量的峰值——即活跃集合大小所达到的最大值。

例：solution([["Q-1","ADD"],["Q-2","ADD"],["Q-3","ADD"],["Q-2","REMOVE"],["Q-4","ADD"]]) 返回 3。前三次 ADD 之后活跃集合为 {Q-1,Q-2,Q-3}，大小为 3；REMOVE Q-2 之后降为 2，再 ADD Q-4 又升回 3。所有快照里的最大值就是 3。

需要明确的细节：空事件流返回 0；对已经活跃的 quote_id 再次 ADD 不会改变集合（同一 ID 不会在活跃集合里出现两次）；任何 ADD 之前的 REMOVE、或对已经被移除的 quote_id 再次 REMOVE，都被静默忽略（幂等）；同一 id 在 REMOVE 之后再次 ADD 是允许的，并按一次新的激活计入。quote_id 按精确字符串身份比较（大小写、前后空白、纯数字字符串都视为不同）。

直接对每个前缀重算活跃集合是 O(N^2)，在 N 接近 500000 的隐藏用例上会超时；用一个活跃 ID 的哈希集合加一个运行中的最大 size，即可在 O(N) 内完成扫描。

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

实践背景

做市商网关上的报价引擎维护着一张"活跃报价表"——交易所端目前挂着的全部 quote_id 集合。每个 ADD 把一条新报价推上去，每个 REMOVE / cancel 把它撤下来；在突发行情、批量撤单触发、会话重试等场景下，引擎瞬间持有的活跃报价数会显著高于稳态值。可靠性看板会追踪并发活跃报价数的峰值，把它作为交易所端报价表内存与撮合 message budget 的最坏情况负载，同时也是一项健康检查——引擎不应对同一 ID 出现重复挂单（重复 ADD 不能让计数膨胀）。把"对非活跃 id 的 REMOVE"视为 no-op 是有意的：在交易所已经 ack 上一次 cancel 之后，重发的 cancel 在生产里是常态，不应让账目逻辑崩掉。