AskaEth
72767067f3
test(m170): 闸顺序用例在 Windows 上也真跑（声明长度自己造 + 反证）
M166 r2 复审的两条「合并后收口」观察：
① `zip64::the_gate_runs_before_any_content_is_opened` 原来量夹具目录的
`metadata().len()`，量到 0 就 `return`——而本机 NTFS 上空目录就是 0（实测：空 0、
第 7 个条目起 4096），于是这条「行为证明」在 Windows 上一条断言都没执行。
现在：先把目录填到长度非零（32 个 filler），拿「声明长度减一字节」当总量上限，
前提不满足就 `assert!`；单条目上限给 `u64::MAX`，不让 `guard_entry` 当替身。
另加一条**反证**：同一份夹具把限额放到 `u64::MAX`，必须死在 `File::open`/`read`
上拿到 `pack_io`——于是上面拿到 `pack_limits` 只能解释为「闸在碰内容之前」。
同时更正 `one_file_over_the_threshold_...` 里那句过头的注释：`leftovers` /
`!target.exists()` 在任何失败路径上都成立，属结构侧检，不是「没读一个字节」的证明。
② `probe.rs` 的模块级 `#![allow(clippy::missing_const_for_thread_local)]` 收窄到
`thread_local!` 内那个 `static` 上（A/B 实测：没带的那组只报一条 lint，带了就干净，
且不判 unused），模块级 allow 不再替未来的真漏 const 打掩护。
变异验证（本机 Windows/NTFS，跑完已还原）：
- 预检挪到 `File::open` 之后 → 本用例红（`left: Io` / `right: Limits`），改前那版全绿；
- 预检改成用 `std::fs::read` 量尺寸 → 同样红；
- 只留结构断言（拆掉 kind/文案/反证）→ 同一变异下**全绿**，证明它们确实区分不了顺序。
2026-11-08 09:54:31 +08:00
..
2026-11-08 09:54:31 +08:00
2026-11-07 17:01:13 +08:00
2026-10-31 21:54:10 +08:00