feat(m160): 整合包逐文件覆盖/保留决策 + 导入前冲突清单 + 限额口径统一

主任务（逐文件覆盖/保留）
- core: 新增 import/scan.rs —— 只读预检产出「冲突清单」（目标已存在且 SHA-1 不同才进），
  逐条给路径/来源/两侧体积与哈希；用户删过的、内容相同的、被叠层遮蔽的一律不打扰。
- core: 新增 import/decision.rs —— ConflictDecisions（整批档 + 逐项表，逐项优先），
  缺省档恒为 KeepUser；ImportRequest.conflict_policy 改由它承载，CLI 调用点不变。
- core: phase.rs 的 settle 按 path 取决策；非冲突路径不受决策影响。
- presenter: ImportScanView / ImportConflictView / ConflictDecisionsView（全部保留 /
  全部覆盖 / 逐项{default,items}）+ PackCommand::Scan / PackEvent::Scan；host 新增只读
  spawn_scan，且新实例路径不再提前建目录（target_of 只算路径，prepare_target 才建）。
- app-iced: 导入前冲突清单页（分页 40 条/页、三入口、计数摘要、确认/取消、两行式行布局）；
  预检干净时直接往下导，不打扰用户。出图见 C:/Temp/m160-shots/{pick-light,pick-dark}.png。
- i18n: 新增 18 条 en/zh 文案 + 更新「两者都留」那条口径说明。

限额口径统一
- pack/archive/limits.rs 成为唯一来源：PACK_MAX_ENTRIES/UNCOMPRESSED_BYTES/ENTRY_BYTES
  （20k / 512 MiB / 64 MiB）；读侧 PackLimits::default 与写侧 WriteLimits::production 同源。
- 写侧不再直接用 zip::ZIP64_BYTES_THR；新增单条目闸，于是「能导出的包一定能导入」。
  不等式在 pack/tests/limits.rs 里用 const 断言钉死。

测试临时物泄漏（塔台追加项）
- addon/temp.rs：TempRoot —— Drop 即删（panic 展开同样删），Deref/AsRef 到落点路径，
  under()/at() 支持"子树落点、删父根"。形状照 core::update::tests::support::TempDir。
- addon::pack 与 addon::tests 两族全部改用 TempRoot（含 fixtures::Fixture 持守卫、
  multimc/fabric_instance 等返回守卫）；4 GiB 稀疏文件的语义一字未改，只改"谁负责删"。
- 自证：pack/tests/mod.rs 三条用例（drop 删 / panic 也删 / 子树删父根）。

测试
- import_decisions.rs（11 例）：预检清单、不打扰、逐项决策后的最终文件集、基线记包内哈希。
- roundtrip_three.rs（2 例）：叠层 + 冲突夹具 import→export→import 三轮文件集逐字节一致，
  以及「选保留就按设计分叉」的反向证据。
- pack/tests/limits.rs（5 例）：单条/总量边界、读侧用同一批常量、写出即可读回。

证据：cargo fmt --check 干净；cargo clippy --workspace --all-targets -D warnings 干净；
cargo test --workspace --all-targets -j 4 → 2507 passed / 0 failed（51 个 test binary）。

crates/core/src/addon/pack/archive/limits.rs

@@ -1,5 +1,22 @@
 //! 读取限额：条目数 / 解压总体积 / 单条目，以及两处封顶实现。
 //!
+//! # 只此一份口径（导入读取 **与** 导出写入共用）
+//!
+//! [`PACK_MAX_ENTRIES`] / [`PACK_MAX_UNCOMPRESSED_BYTES`] / [`PACK_MAX_ENTRY_BYTES`] 是**唯一**
+//! 的体积口径：读侧 [`PackLimits::default`] 从这里取，写侧 `pack::format::write` 的预检也从
+//! 这里取（以前写侧直接拿 `zip::ZIP64_BYTES_THR`，于是"导得出来、导不回去"——导出允许 ~4 GiB，
+//! 导入只允许 512 MiB）。现在的关系是硬约束：
+//!
+//! ```text
+//! PACK_MAX_ENTRY_BYTES ≤ PACK_MAX_UNCOMPRESSED_BYTES < PACK_ZIP64_BYTES_THR ≤ u32::MAX
+//! ```
+//!
+//! 所以「我们能写出的包一定能被自己读回来」，而 ZIP64 阈值退化成一条**不会再被触碰的**
+//! 物理上限（`tests/limits.rs` 钉住这条不等式，也钉住两侧用的是同一批常数）。
+//!
+//! 为什么不让写侧跟着 ZIP64 放宽：读侧把单条目整条读进内存（[`read_capped`]），64 MiB 是**内存**
+//! 护栏；放宽它等于用一个看不见的内存峰值换一个几乎用不到的大包能力。
+//!
 //! # 两阶段限额（打开 vs 读取）
 //!
 //! 打开阶段（[`check_limits`]）只能拿**中央目录声明的大小**做判断——它会撒谎。
@@ -13,12 +30,24 @@ use std::io::Read;
 
 use super::super::error::{PackError, PackResult};
 
-/// 默认条目数上限（一个巨型整合包 ≈ 数千条，2 万条已经很宽）。
-pub const DEFAULT_MAX_ENTRIES: usize = 20_000;
-/// 默认解压总体积上限（512 MiB；`.mrpack` 的 `overrides` 通常几十 MiB）。
-pub const DEFAULT_MAX_UNCOMPRESSED_BYTES: u64 = 512 * 1024 * 1024;
-/// 默认单条目上限（64 MiB；最大的 mod 也不过十几 MiB）。
-pub const DEFAULT_MAX_ENTRY_BYTES: u64 = 64 * 1024 * 1024;
+/// 条目数上限（一个巨型整合包 ≈ 数千条，2 万条已经很宽）。
+pub const PACK_MAX_ENTRIES: usize = 20_000;
+/// 解压/打包总体积上限（512 MiB；`.mrpack` 的 `overrides` 通常几十 MiB）。
+pub const PACK_MAX_UNCOMPRESSED_BYTES: u64 = 512 * 1024 * 1024;
+/// 单条目上限（64 MiB；同时是读侧的**内存**护栏与写侧的单文件护栏）。
+pub const PACK_MAX_ENTRY_BYTES: u64 = 64 * 1024 * 1024;
+/// ZIP64 的物理阈值（`zip` crate 的口径，≈4 GiB）。
+///
+/// 生产路径**不再**用它当判据：PACK_MAX_UNCOMPRESSED_BYTES 远低于它（0.5 GiB ≪ 4 GiB），
+/// 所以 `tests/limits.rs` 只需钉住"统一上限 < 本阈值"，ZIP64 就永远不会被需要。
+pub const PACK_ZIP64_BYTES_THR: u64 = zip::ZIP64_BYTES_THR;
+
+/// 默认条目数上限（= [`PACK_MAX_ENTRIES`]，保留旧名以免破坏既有调用点）。
+pub const DEFAULT_MAX_ENTRIES: usize = PACK_MAX_ENTRIES;
+/// 默认解压总体积上限（= [`PACK_MAX_UNCOMPRESSED_BYTES`]）。
+pub const DEFAULT_MAX_UNCOMPRESSED_BYTES: u64 = PACK_MAX_UNCOMPRESSED_BYTES;
+/// 默认单条目上限（= [`PACK_MAX_ENTRY_BYTES`]）。
+pub const DEFAULT_MAX_ENTRY_BYTES: u64 = PACK_MAX_ENTRY_BYTES;
 
 /// 包读取限额。
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]