fix(m196): r1 复审 P1（非 Windows dead_code）+ P2 四条

P1（阻断）：console.rs 的 `INVALID_HANDLE_VALUE` 只被 `#[cfg(target_os = "windows")]`
的 usable() 用到，而这个模块在 Linux/macOS 上也编译（platform/mod.rs 的 pub mod win32;
没有 cfg）⇒ ubuntu 的 `clippy -- -D warnings` 会把它升级成 dead_code error。
按「精确 cfg」修（不用 dwm.rs 那种文件级 allow(dead_code)：那会永久掩掉本文件在非
Windows 上的所有死项）。自证方式是真实文件翻转 cfg 的 rustc probe：修前 exit 1
（`constant INVALID_HANDLE_VALUE is never used`）、修后 exit 0 零告警；同一条命令写进
了注释，下一个人可以照着跑。

P2-1：自测条数按实现改成 8 条（红 6 / 绿 2），三处（脚本 docstring、release-build.yml
注释、README §12）一致。
P2-2：文件头那组句柄读数换成 release 产物的实测值（out 0x0→0x1F0 / err 0x0→0x1F4），
并说明数字随实例变化、单测里的 0xE4/0xE8 是示例。
P2-3：README §15 补这段边角语义——但**按实测改写了复审的结论**：两种「既无控制台也不
重定向」的宿主形态（父有句柄不继承 / 父子都无句柄）× 两条命令，child_exit_code 全是 0，
不是 EXIT_INTERNAL；原因是 Rust std 在 Windows 上对取不到的句柄直接返回 Ok（独立探针
实测 SetStdHandle(out)=0x0 / 0x1234 / (HANDLE)-1 三种取值 write/flush 都是 Ok），
所以 runner.rs 那条「写失败 ⇒ EXIT_INTERNAL」的分支不会被触发。
P2-4：NoParentConsole → NoConsole（这个名字同时覆盖「attach 成功但句柄仍不可用」），
诊断文案与注释同步。

packaging/README.md

@@ -65,7 +65,7 @@ Git Bash 下会静默落进 Docker VM（脚本内部用 `cygpath -m` 归一）
 | `packaging/release-notes.md` | GitHub Release 说明模板（`{{VERSION}}` / `{{SUMS}}` 占位） | ≤400 |
 | `packaging/check_screenshot.py` | 截图非空白判定（CI 门禁 + 本地手动跑，零第三方依赖） | ≤400 |
 | `packaging/check_publish_slots.py` | 发布名单守卫（M164）：名单 ⇄ 产物两个方向；`--self-test` 注入 8 条回归 | ≤400 |
-| `packaging/check_pe_subsystem.py` | PE 子系统守卫（M196）：**读产物 PE 头的 `Subsystem`**（GUI 必须 2 / CLI 必须 3），非 2 即红；`--self-test` 注入 5 条回归（见 §15） | ≤400 |
+| `packaging/check_pe_subsystem.py` | PE 子系统守卫（M196）：**读产物 PE 头的 `Subsystem`**（GUI 必须 2 / CLI 必须 3），非 2 即红；`--self-test` 注入 8 条回归（红 6 / 绿 2）（见 §15） | ≤400 |
 | `packaging/check_test_source_off.py` | 测试通道守门（M169）：workflow / 打包脚本 / `Cargo.toml default` 都不许打开 `update-test-source`；归属按 `jobs.*.steps[]` 列表项判、默认拒绝；`--self-test` 按 `tests/guard_vectors.json` 注入 | ≤400 |
 | `packaging/tests/guard_vectors.json` | 守门自测向量（基线 + 32 条：26 红 / 6 绿），数据与代码分开 | ≤400 |
 | `packaging/ci-runtime-smoke.md` | §11 的细节：断言口径/阈值依据/失效模式/复跑 | ≤400 |
@@ -158,10 +158,22 @@ CUI(3)，`grep -rn windows_subsystem crates/` 当时零命中。同一个修复
   四种启动情形的实测表在该文件顶部）：重定向/管道两个句柄本来就可用（一个字节都不动）、cmd 里直接跑
   附着后输出落进控制台、双击时附着失败且**绝不新建窗口**。
 - 守门：`python3 packaging/check_pe_subsystem.py --gui <exe> --cli <exe>`，读 `MZ`→`e_lfanew`(`0x3C`)→
-  `PE`→COFF 头→可选头 `+0x44` 的 2 个字节，打印**文件偏移**（例：`Subsystem=2 (WINDOWS_GUI) @
-  文件偏移 0x1E6`）。两向断言：GUI 产物必须 2，CLI 产物 `ull.exe` 必须仍是 3（CONSOLE）——反方向
-  不守时，把属性贴错 crate 会被漏掉，而 `ull --version | …` 会静默丢输出。
+  `PE\0\0`→COFF 头→可选头 `+0x44` 的 2 个字节，打印**文件偏移**（release 产物实测：`Subsystem=2
+  (WINDOWS_GUI) @ 文件偏移 0xDC`，`e_lfanew=0x80`、PE32+）。两向断言：GUI 产物必须 2，CLI 产物
+  `ull.exe` 必须仍是 3（CONSOLE）——反方向不守时，把属性贴错 crate 会被漏掉，而 `ull --version | …`
+  会静默丢输出。
 - 接在哪：`.github/workflows/release-build.yml`（发布侧，两个 Windows 槽位各跑一次）与
   `.github/workflows/ci.yml` 的 `build` job（PR 阶段就红，不必等到 tag）。
 - 抓不住（如实记）：只看那 4 个字节，不看 GUI 双击的实际观感——「不再多一个黑框」在本仓库的验证环境
   （RDP / 无干净无控制台桌面）只能由 PE 头 + 进程/窗口枚举间接证明，人眼验收归真机。
+- **既无控制台也不重定向的宿主（快捷方式 / 服务 / 计划任务）：输出照旧无处可去，退出码不变**
+  （M196 r2 实测，覆盖 r1 复审 P2-3 提出的「退出码会变成 `EXIT_INTERNAL`(2)」——那条实测不成立）。
+  两种宿主形态各测两条命令，`child_exit_code` 全是 **0**：①父进程有 std 句柄但子进程不继承；
+  ②父子都没有 std 句柄（服务形状，子进程实测 `stdin/stdout/stderr = 0x0`、`AttachConsole` 返回 0 /
+  `GetLastError=6`）。原因在 Rust std 的 Windows 实现：句柄取不到时 `Write`/`flush` 直接返回 `Ok`
+  （独立探针实测 `SetStdHandle(out)` = `0x0` / `0x1234` / `(HANDLE)-1` 三种取值，`write=Ok(())`、
+  `flush=Ok(())` 全成立），所以 `crates/cli/src/runner.rs` 那条「写失败 ⇒ `EXIT_INTERNAL`」的分支不会
+  被触发。结论：本 diff **没有**给 CLI 退出码引入可观察差异；真正的差异只有「没控制台就没人看得见输出」
+  这件事，而 CUI 时代在服务里同样是隐形的。想让这种情形有专属退出码/文案，得在 CLI 侧显式判一次能力
+  （`platform::win32::console` 的 `output_visible()` 就是现成的判据），那在 `crates/cli/**`、不在 M196 的
+  scope 内——这里只如实记录形态，不改结构。