perf(build): 加 fast 构建档、依赖并行 codegen、验收脚本一次 --bins

三条慢因里两条落在构建配置上，发布档（release）的体积取向不动：

1. `[profile.fast]`（inherits = release）：opt-level 2 / lto thin / codegen-units 16，
   日常迭代与验收用它，发布仍走 release。`panic = "unwind"` 是**必须显式写**的一行——
   release 是 panic = "abort"，inherits 会照抄，漏了它 `cargo test --profile fast` 起不来
   （test harness 依赖 unwind）。
2. `[profile.release.package."*"]`：依赖的 codegen-units 放到 16（并行 codegen），
   **opt-level 保持 "z"**。最初按「优化等级高 = 编译快」把依赖抬到 opt-level 3，
   同机冷编译实测反了：opt-3 是 22m45s / GUI 19.46 MiB，opt-"z" 是 16m01s / 15.72 MiB——
   又慢 29.6% 又大 19~24%，收益全部来自 codegen-units 而不是 opt-level。
   只调优化强度，不碰 panic / strip（那两项改的是整个二进制的运行时行为）。
3. `[profile.fast.package."*"]` 显式写一遍：package 覆盖按 profile 分别生效，不赌 inherits
   会不会连覆盖一起继承（实测 594 个编译单元全部 opt-level=2 + cu16，含依赖）。

实测写进 packaging/README §6/§7.1（同机、删空 target 的冷编译、无并发负载）：
release 16m01s（GUI 15.72 / iced 13.27 / ull 5.97 MiB），fast 24m27s（36.41 / 32.02 / 15.23 MiB）。
**fast 档在本机冷编译没有收益甚至更慢**，瓶颈是两个大 UI crate + 链接 + 机械盘 IO，
它的定位是 SSD 机器与增量重编——这条照实写进文档，不为了贴近预期挑数字。

DevDocs/ops/macos-acceptance.sh 的构建段改动（DevDocs 被 gitignore，无法入库）见完成报告。

Cargo.toml

@@ -108,3 +108,43 @@ lto = "fat"
 codegen-units = 1
 panic = "abort"
 strip = "symbols"
+
+# P6（M96）：日常迭代 / 本机验收用的「快」档，发布仍走上面的 release。
+# `inherits = "release"` 让其余各项（strip / debug / overflow-checks …）照抄 release，
+# 只覆盖拖慢构建的四处：
+# - lto = "thin"：跨 crate 内联仍有，但可以并行；fat LTO 在 codegen-units = 1 下等于
+#   全程序串行链接（375 个 crate 排队），一次性吃掉十几分钟。
+# - codegen-units = 16：给 codegen 留并行度，不再把整个 crate 挤成一个 CGU。
+# - opt-level = 2：介于 "z" 与 3 之间，"z" 会为了体积关掉一批循环/内联优化，代价是运行期。
+# - panic = "unwind"：**必须显式写**。release 是 panic = "abort"，inherits 会照抄下来，
+#   而 test harness 依赖 unwind —— 漏了这行 `cargo test --profile fast` 直接起不来。
+#
+# ⚠️ 定位（实测，别误读）：本机（12 核 + 机械盘源码盘 + -j 4）冷编译 fast = 24m27s，
+# **比 release 的 16m01s 还慢**，体积是 2.3 倍（36.41 vs 15.72 MiB GUI）。瓶颈在两个大
+# UI crate 的编译 + 链接 + 磁盘 IO，LTO/CGU 这几个旋钮被掩盖了。它的价值在 **SSD 机器**和
+# **增量重编**（thin 不必每次全程序 LTO）；「加了 fast 档」≠「冷编译会变快」。
+[profile.fast]
+inherits = "release"
+opt-level = 2
+lto = "thin"
+codegen-units = 16
+panic = "unwind"
+
+# P6（M96）：依赖不需要为体积做极致优化，但**实测结论与直觉相反**——把依赖的 opt-level 从
+# release 的 "z" 抬到 3（本档最初就是这么定的）会让冷编译**更慢**、体积还更大：
+# 同机冷编译 opt-3 = 22m45s / 19.46 MiB（GUI），opt-"z" = 16m01s / 15.72 MiB。
+# 真正的收益全在 `codegen-units = 16`（并行 codegen），与 opt-level 无关；抬等级是在拿编译时间
+# 和体积换运行期。所以这里**只放宽并行度，opt-level 保持 "z"**，workspace 自己的 crate 仍吃
+# opt-level = "z" / 单 CGU。
+# **只调优化强度**：panic 与 strip 绝不写进这里。那两项改变的是整个二进制的运行时行为
+# （panic 策略决定能否 unwind 出栈、strip 决定符号表留不留），不是「给依赖放宽」的范畴。
+[profile.release.package."*"]
+opt-level = "z"
+codegen-units = 16
+
+# 快档的依赖覆盖单独写一遍：package 覆盖是按 profile 分别生效的（`[profile.release.package."*"]`
+# 只作用在 release 档），显式写出来就不必赌 `inherits` 会不会连 package 覆盖一起继承。
+# 值与 fast 档自身一致——依赖编得快是快档的目的，不是再抬一档优化强度。
+[profile.fast.package."*"]
+opt-level = 2
+codegen-units = 16