fix: improve suffix range and open-ended range handling

[sendya]

概述

修复 issue #63 — 客户端发送 suffix range（如 Range: bytes=-512）时的两个 bug：

1. multirange 中间件错误拒绝 suffix range：原有代码对所有 rangecontrol.Parse 失败都返回 416，但 suffix range 是 RFC 7233 合法的 HTTP Range 格式，multirange 不应拦截单 suffix range。
2. fillRange 将 suffix range 计算为 MaxInt64 无效范围：未知对象大小时用 math.MaxInt64 推导 suffix range 起始位置，导致生成天文数字的 Range 头发送到上游。

修改内容

P0: multirange 透传单 suffix range

• 使用 rangecontrol.Parse(rawRange, math.MaxInt32) 替代自定义 hasSuffixRange
• 单 range（含 suffix range）透传到下一层
• 无效 range（如 bytes=abc, bytes=-）返回 416
• 混合 suffix multi-range（如 bytes=0-99,-512）在未知对象大小时拒绝

P0: fillRange 绕过不可解析 range

• hasSuffixRange → hasUnresolvableRange，同时检测 suffix range 和 open-ended range
• 未知对象大小时绕过，避免 MaxInt64 计算

P0: rangecontrol.Parse 支持 totalSize

• 接受 totalSize 参数以解析 suffix range
• suffix range 超过对象大小时跳过（而非生成负数 start）

其他

• internal.go: 新增 rng nil 检查防止 panic
• 新增 benchmark 测试

边界情况

场景	修复前	修复后
bytes=-512 cache MISS	MaxInt64 无效范围	透传到上游
bytes=-512 cache HIT	416	使用已知 Size 正确返回
bytes= -512	可能异常	识别为 suffix range 透传
bytes=0-99,-512	可能被错误处理	未知大小时 416
bytes=100- cache MISS	MaxInt64 无效范围	透传到上游
bytes=abc	416	保持 416

Closes #63

🤖 Generated with Claude Code