feat(download): 分块路径写续传元数据并自证旧字节（M293）

台账 P21 第 2 条 + P19(b)：分块路径此前进来先 `part.discard()`、失败也 `discard()`，
188MB 的 JDK 任何一次失败都从 0 重下；M289 又给预算耗尽加了「不再重试、不再换源」的
短路，慢链路上一次晚到的失败就变成「这个文件下不来」。

写这一侧：
* `ResumeMeta` 新增 `chunks: Option<Vec<ChunkRecord>>`（段区间 + 该段 SHA-1），
  由新增的 `chunk_resume::ChunkJournal` 每成功回收一段就原子落一次盘；
* `fetch_chunk` 顺带带回段摘要、`Content-Range` 总长与 ETag/Last-Modified，
  所以元数据里同时有 total / 源 URL / 分块清单 / 校验所需信息；
* 分块失败不再丢中间文件，只有 `RangeUnsupported`（单连接接不住这种形状）才丢。

判这一侧：
* `chunk_resume::decide`（纯函数）要求策略允许、URL / 总长 / 摘要 / 校验器全对得上，
  且每条记录精确命中本次分块规划里的一段，否则从头再来；
* `chunk_resume::verify_records` 按记录重读旧段、重算摘要：任何一段对不上就整份丢掉
  （元数据本身已不可信，同批其它记录也不再被信任）；
* 续传的段请求带 `If-Range`，让服务器回答「内容变了没有」；
* 整文件摘要照旧在末尾整份重算，覆盖新下 + 复用的全部字节。

单连接路径零改动：`resume::decide` 的判定一字未动，只新增
「元数据里带分块清单 ⇒ 强行判 Restart 交给分块路径」这一条，避免预分配全长文件被
单连接的 `Complete` 误判成「已下满」。

判据（都是「服务端实际吐了多少字节」，不是「最终 hash 对」）：
* 3/4 处失败后续传完成：41984 字节 / 40960 文件 = 1.025×（断言 < 1.5×）；
* 变异（关掉续传同样夹具）：72704 = 1.775×，`< 1.5×` 必红（已实测）；
* 变异（去掉旧段摘要自证）：坏段被复用 ⇒ 51200 ≠ 40960 必红（已实测）；
* 变异（去掉总长比较）：旧大小的段被复用 ⇒ 61440 ≠ 40960 必红（已实测）。

crates/core/tests/download/resume_test.rs

@@ -5,6 +5,10 @@ use unlucky_core::download::resume::{
 };
 use unlucky_core::download::types::{HashAlgo, ResumePolicy};
 
+/// 分块路径的续传判定与旧字节自证（M293）：拆到子模块守 400 行硬线。
+#[path = "resume/chunk.rs"]
+mod chunk;
+
 const URL: &str = "https://bmclapi2.bangbang93.com/versions/1.20.1/client.jar";
 const HASH: &str = "0123456789abcdef0123456789abcdef01234567";
 
@@ -17,6 +21,7 @@ fn meta(url: &str) -> ResumeMeta {
         algo: HashAlgo::Sha1,
         hash: HASH.to_string(),
         saved_at_ms: 1,
+        chunks: None,
     }
 }