走簿打穿：贪心最小成本撮合

实现 solution(Q: int, offers: list[list[float]]) -> float。给定一个目标买入数量 Q（非负整数）以及一份合成订单簿 offers，每一档的形式为 [price, size]（price > 0，size >= 1）。返回严格按从低价到高价吃簿所能得到的最小总成本——同价档之间任意排列都得到同样的总成本，而最后一档可能被部分消耗：只买入还需要的那部分股数，不必把整档吃完。

若 Q == 0，返回 0.0；若 sum(size for price, size in offers) < Q（即全部档位加起来都凑不齐 Q 股），返回 -1.0，表示这一目标在当前簿上不可成交。

例

solution(6, [[10.5, 3], [9.0, 4], [11.0, 5]]) 返回 57.0。按价格升序重排后是 [[9.0, 4], [10.5, 3], [11.0, 5]]：先把 [9.0, 4] 整档吃完（4 * 9.0 = 36.0），剩余 2 股从 [10.5, 3] 中部分消耗（2 * 10.5 = 21.0），合计 36.0 + 21.0 = 57.0，第三档 [11.0, 5] 完全未被触碰。

朴素的"每股扫描一遍 offers 找最便宜档"是 O(Q*N)，在 Q 接近 1e12 的隐藏用例上无法在 2 秒内跑完。期望解法：先按价格升序排序，再从前往后累加 size * price，途中维护剩余需买量；当某档 size > remaining 时只买 remaining * price 并立即返回。同时先完整算出 sum(size) 与 Q 比较——只在确认可行后才进入累加路径。

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

实践背景

在执行端，"如果我现在按某 VWAP 切片把这一笔单挂出去吃簿，最便宜需要花多少？"是定盘价基准（cost-basis benchmark）的标准计算；它给出的是路由器在没有任何对手抢跑、没有价格滑落的"理想极限"，自然也成了实盘真实成本回归到该基准的差额——也就是滑点 (slippage) 的定义。solution(Q, offers) 把"贪心吃簿"这一原语单独拎出来：在策略实测里，它每个 tick 都会被调用以更新策略 PnL 的"盈亏归因到簿"分项；在合规端，它也用于"如果一定要立即清掉这部分库存，最优情形下要付多少？"的强平估算。算法本身只是"排序加累加"的简单贪心，但在执行台账上它是可被反复引用的基础积木。