[Feature] RangeReadReadAtSeeker 游标查找线性退化

请确认以下事项

• 我已确认阅读并同意 AGPL-3.0 第15条 。
  本程序不提供任何明示或暗示的担保，使用风险由您自行承担。

• 我已确认阅读并同意 AGPL-3.0 第16条 。
  无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。

• 我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。

• 我已确认阅读了OpenList文档。

• 我已确认没有重复的问题或讨论。

• 我认为此问题必须由OpenList处理，而非第三方。

• 我已确认此功能尚未被实现。

• 我已确认此功能是合理的，且有普遍需求，并非我个人需要。

• 我没有阅读这个清单，只是闭眼选中了所有的复选框，请关闭这个 Issue 。

需求描述

在 [OpenList/internal/stream/stream.go:444]：

• 每次 ReadAt 都调用 sync.Map.Range 扫描所有已保存 offset。
• 每次成功读取又在 [stream.go:504]保存新的 continuation reader。
• 随机访问越多，reader map 越大，查找成本从近似 O(1) 退化为 O(N)。
• 这些 reader 还可能持有未关闭的 HTTP response body，导致连接和对象生命周期变长。
  这会直接影响 ZIP、RAR、ISO、视频拖动播放等随机读取场景。

实现思路

用有序 offset 结构或区间缓存替代 sync.Map.Range。
对 continuation reader 设置最大数量或按窗口淘汰。
对相同 offset 的并发读取增加 singleflight，避免重复 Range 请求。
增加“连续顺序读、随机读、交错读”的 benchmark。

附加信息

No response

AI生成内容（可选）

No response

Start at internal/stream/stream.go:444 and :504 to trace how ReadAt searches offsets and stores continuation readers. Define and validate the replacement lookup, reader lifetime limits, and same-offset concurrency behavior; done should include benchmarks for sequential, random, and interleaved reads.