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 成功但句柄仍不可用」），
诊断文案与注释同步。

.github/workflows/release-build.yml

@@ -265,7 +265,7 @@ jobs:
       # 就是这么活到 2026-11-08 的。本步只认那 4 个字节：GUI 产物必须是 WINDOWS_GUI(2)，非 2 即红。
       # 反方向一并守：CLI 产物 `ull.exe` 必须仍是 CONSOLE(3)——它靠真控制台做 stdout/stderr，
       # 谁把属性抄到它头上，`ull --version | …` 会静默丢输出。守门本体在 packaging/check_pe_subsystem.py
-      # （零第三方依赖，本地同一份代码可跑；`--self-test` 注入 5 条回归证明它会红）。
+      # （零第三方依赖，本地同一份代码可跑；`--self-test` 注入 8 条回归（红 6 / 绿 2）证明它会红）。
       - name: PE 子系统门禁（GUI 产物必须 WINDOWS_GUI/2，CLI 产物必须 CONSOLE/3）
         if: runner.os == 'Windows'
         shell: bash