最大同时在仓交易数
Maximum Concurrent Trades
开始编码风险台一直在盯一个数字：任意时刻最多有多少笔 trade 同时挂在账上。这数字直接绑死保证金占用、绑死给 PM 的 position-count 限额、也绑死 reconciliation 系统能多大并发地处理 trade 事件。回测工程师在跑历史 fill 数据时也会先算一遍这个值，确保策略产生的 trade 流不会把 prime broker 的 trade-id pool 撑爆。
给你一份 trades 表，每笔形如 [open_time, close_time]：trade 在 open_time 时进入持仓、在 close_time 时被平掉。请实现 solution(trades: list[list[float]]) -> int，返回在所有时刻里同时在仓的 trade 数的最大值。
关键约定：trade [o, c] 占用持仓的时间是**半开区间 [o, c)——也就是说，如果一笔 trade 在 t=5 平仓、另一笔在 t=5 开仓，则二者不算同时在仓**（前者的 [o, c) 在 t=5 已经不再持有）。这是 risk-counting 里的标准约定：平仓事件先于开仓事件结算，避免把一笔“关一笔再开一笔”的 rebalance 算成两笔同时挂账。
例如 solution([[1.0, 5.0], [2.0, 6.0], [4.0, 7.0]]) 应返回 3：在 t ∈ [4.0, 5.0) 这段时间内三笔 trade 同时在仓。再如 solution([[1.0, 3.0], [3.0, 5.0]]) 应返回 1：第一笔在 t=3 平仓、第二笔在 t=3 开仓——根据半开区间约定它们不视为同时在仓，所以最大并发是 1，不是 2。
数据规模到 5 万笔，朴素的 O(N²) 双重循环在边界用例上会超时。标准解法是把开/平拆成事件后排序（O(N log N)），或者把开仓时间和平仓时间各自排序后用双指针推进——这两种写法都是 sweep-line 思路，也是这题被放进“贪心 + 区间”簇的原因。
约束条件
- 0 ≤ len(trades) ≤ 50000
- 每笔 trade 形如 [open_time, close_time]，open_time < close_time（严格小于；不存在零时长的 trade）
- open_time, close_time 是浮点数，允许为负（用相对时间戳是常见的回测约定），|t| ≤ 1e12
- trades 列表本身**不保证按 open_time 排序**
- 重叠语义：trade `[o, c]` 视为占用半开区间 `[o, c)`——同一时刻 A 平仓、B 开仓不计为重叠
- 返回 int：任意时刻在仓 trade 数量的最大值；空 trades 返回 0
样例
Case 1 · three overlapping trades, peak of 3 in [4.0, 5.0)
输入: [[[1,5],[2,6],[4,7]]]
期望: 3
trade A=[1,5)、B=[2,6)、C=[4,7) 在 t ∈ [4.0, 5.0) 这段同时在仓，所以最大并发是 3。
Case 2 · half-open boundary: close-then-open at same instant counts as 1
输入: [[[1,3],[3,5]]]
期望: 1
第一笔在 t=3 关、第二笔在 t=3 开。按半开区间约定 [o, c)，前者在 t=3 已不再在仓，所以最大并发是 1（不是 2）。
最近提交
还没有提交记录。
编码区
实现 solution(...)。本地运行当前支持 Python 可见样例；服务端提交会运行可见样例和隐藏测试。
默认展示公开样例。点击「运行样例」后会在这里显示实际输出；点击「提交评测」会进入隐藏测试。
Case 1 · three overlapping trades, peak of 3 in [4.0, 5.0)
输入: [[[1,5],[2,6],[4,7]]]
期望: 3
trade A=[1,5)、B=[2,6)、C=[4,7) 在 t ∈ [4.0, 5.0) 这段同时在仓，所以最大并发是 3。
Case 2 · half-open boundary: close-then-open at same instant counts as 1
输入: [[[1,3],[3,5]]]
期望: 1
第一笔在 t=3 关、第二笔在 t=3 开。按半开区间约定 [o, c)，前者在 t=3 已不再在仓，所以最大并发是 1（不是 2）。