test(m166): zip64 夹具改用小 limits，去掉 8.5 GiB 真落盘

`set_len` 造的所谓稀疏文件在 NTFS 上并不稀疏：实测 `SetLength(1 GiB)` 之后
C 盘可用空间正好掉 1024 MiB。于是 `zip64.rs` 那两条用例的声明尺寸
（`u32::MAX + 1` ≈ 4 GiB 加 `3 × 1.5 GiB` = 4.5 GiB）就是 8.5 GiB **真占用**，
再加上 `write/tests.rs` 的 3 GiB 与 `limits.rs` 的三条 64 MiB 级用例，
单次跑的落盘峰值到过 ~12 GiB。

判据本身跟夹具大小无关（吃的是 `metadata().len()`），所以把 limits 做成参数：
`format::write_with_limits` 是 `PackFormat::write` 的实体，生产路径仍只传
`WriteLimits::production()`，测试传 KiB 级小值走**同一条** `preflight` 分支。
`WriteLimits` 的可见性顺势开到 `pub(in crate::addon::pack)`。

GiB 级的**数值判定**搬进 `format/write/tests.rs` 的纯算术用例：>4 GiB（撞 ZIP64
阈值即拒、差一字节放行）与 >2 GiB（M152 那个 2.5 GB 样本现在按统一上限拒），
以及第二道闸 `Written` 在同一批数值上的行为——两道闸吃的都是 u64，不需要落盘。

断言一条没删、用例一条没新加 `#[ignore]`（反而把旧的那条 `#[ignore]` 的
2.5 GB 用例换成会跑的 KiB 级版本，补上 `guard_entry` 分支的端到端覆盖）。

扫描：`grep -rn 稀疏 crates/ packaging/ docs/` 里凡写着"稀疏文件不占磁盘"的
注释一并改成实测口径（含 `addon/temp.rs`），避免下一个人照着再踩一次。

crates/core/src/addon/temp.rs

@@ -8,7 +8,8 @@
 //!
 //! # 为什么不能靠"系统会清 `%TEMP%`"
 //!
-//! 那种清理要等时间或外部工具，而 `zip64` 那族用例每个要造 4 GiB 的**稀疏文件**验阈值：
+//! 那种清理要等时间或外部工具，而 `zip64` 那族用例历史上每个要造 4 GiB 的"稀疏"文件验阈值
+//! （**实测在 NTFS 上 `set_len` 真占空间**，见 `pack/tests/zip64.rs` 的模块文档）：
 //! M160 r2 实测 `%TEMP%/ull-pack-*` 堆到 **1651 个目录 / 110 GB**，把整台机器（含别的 agent
 //! 的构建）一起顶死。所以测试自己负责收尾，并且有自证用例
 //! （`pack/tests/mod.rs` 的 `the_temp_root_is_gone_once_dropped` /