merge: 解 origin/dev 三处冲突（M182 / M184+M190 / README §14），两边都留

冲突（都来自别人后来改同一批文件）：
- crates/app-iced/src/platform/mod.rs：保留 M182 的 HostOs / host·linux·macos 分册表 /
  plan_corner_for，同时保留 M196 的 `[`win32::console`]` 落点说明；把 M182 措辞里已经不
  成立的「唯一 unsafe 落点 / 只此一处」改成「两处落点（transparency + console）」
  （unsafe-scope 门禁自 M196 起期望集合就是两处，不改这句文档就是错的）。
  注意：`pub mod console;` 属于 `platform/win32/mod.rs`，本次解冲突时一度被误加到
  `platform/mod.rs`（`cargo check` 立刻报 E0583 文件不存在），已修回。
- .github/workflows/release-build.yml：M190 的「PE 版本资源读回」步、M184 的
  linux-x64 xvfb 冒烟步与首帧上传步**全部逐字保留**；M196 的 PE 子系统门禁作为**兄弟步**
  插在导入表门禁之后（两道 PE 门禁互不替代）。按块比对：dev 的 10 个步骤逐字未变，
  合并后 11 个步骤。
- packaging/README.md：保留 M184 的 §11 补充与 §12 行、M190 的 §14 签名段；§12 里
  check_publish_slots 用 dev 的 11 条版本、另加 M196 的 check_pe_subsystem 行；§15 归位在
  §14 之后。

行数：release-build.yml 合并后 413 行会撞 400 行红线（dev 侧本来 393），故把 M196 那一步
压到 6 行 + 1 空行（说明改由步骤名指路 packaging/README.md §15 与脚本 docstring 承载），
最终正好 400 行。

验证见 mission 报告：cargo check/test/fmt 全绿，两个 PE 门禁在同一批产物上都 exit 0
（子系统 GUI=2 / CLI=3，版本资源的 subsystem 读数同为 2 / 3）。

crates/app-iced/src/platform/mod.rs

@@ -1,10 +1,11 @@
-//! 平台相关的窗口能力（P4 / D36 / M116）：整窗透明度与窗口圆角的**判据**、两处 `unsafe` 落点，
-//! 以及系统语言真值源——每一件各归一处（判据不碰 FFI，FFI 只住落点文件）。
+//! 平台相关的窗口能力（P4 / D36 / M116 / M168 / M182 / M196）：整窗透明度与窗口圆角的**判据**、
+//! 两处 `unsafe` 落点、系统语言真值源、以及数据根派生——每一件各归一处（判据不碰 FFI，
+//! FFI 只住落点文件）。
 //!
 //! - 本文件 = 整窗 α 的纯判据 [`effective_window_alpha`]：不读环境变量、不调 FFI、不碰窗口句柄，
 //!   只回答「按这个渲染后端和用户要的 α，最终该给窗口什么值」；
-//! - [`win32::corner`] = 圆角的纯判据 [`plan_corner`]（M116）：用户策略 × 系统版本 × 渲染档 →
-//!   来源与原因码。两个判据都**不碰** FFI，因此都能被断言证明；
+//! - [`win32::corner`] = 圆角的纯判据 [`plan_corner`] / [`plan_corner_for`]（M116 / M182）：
+//!   用户策略 × 宿主平台 × 渲染档 → 来源与原因码。两个判据都**不碰** FFI，因此都能被断言证明；
 //! - [`win32::transparency`] = 整窗 α 的 FFI 落点（补 `WS_EX_LAYERED` +
 //!   `SetLayeredWindowAttributes`，以及 M116 的 `DwmSetWindowAttribute`）；
 //! - [`win32::console`] = M196 的控制台附着落点（`AttachConsole`）：GUI 子系统进程的输出
@@ -14,20 +15,39 @@
 //!
 //! 为什么判据要单独拎出来：D36 的降级规则（α 下限 0.08 / `≤0` 一律拒绝 / CPU 档也允许
 //! 窗口级 α）**可以**被断言证明；而 FFI 的**视觉**结果在本仓库的验证环境（RDP + 虚拟显示
-//! 适配器）上没有参考价值。把可测的那一半独立出来，才有「有测试的判据 + 没测试的观感」这条
-//! 诚实的分界。
+//! 适配器、无 Mac 真机）上没有参考价值。把可测的那一半独立出来，才有「有测试的判据 +
+//! 没测试的观感」这条诚实的分界。
+//!
+//! ## 平台分册（M182：非 Windows 不再是「未知」一格）
+//!
+//! | 模块 | 里面有什么 | 有没有 FFI |
+//! |---|---|---|
+//! | [`data`] | 数据根派生（字体缓存分区 + 一条设置键的生效值，M168） | 没有 |
+//! | [`host`] | [`HostOs`]：平台族的**值**（判据的输入，不是散落的 `cfg`） | 没有 |
+//! | [`macos`] | macOS 为什么是直角的三环证据 + 「迁移原生标题栏」的未实现配方 | 没有（本轮只有文档） |
+//! | [`linux`] | X11 / Wayland 谁负责圆角、为什么我们不自绘 | 没有（本轮只有文档） |
+//! | [`win32`] | Windows 的实现与探针（DWM / 分层 / 控制台附着） | **有**（两处落点：`transparency` + `console`） |
+//!
+//! 两个新平台模块**只有文档、没有代码**：M182 的裁决是不实现（macOS 要动手就得先迁移原生标题栏，
+//! 那会引入两套窗口控件，必须连着撤掉自绘三键 + 真机验收一起做）。把结论写在这里而不是写进报告，
+//! 是因为报告会随会话消失，而下一轮动这块的人一定先读代码。
 
 use unlucky_presenter::prefs::WINDOW_ALPHA_MIN;
 
 use crate::Backend;
 
 pub mod data;
+pub mod host;
+pub mod linux;
 pub mod locale;
+pub mod macos;
 pub mod win32;
 
-/// 窗口圆角的**判定**（M116）住在 `win32::corner`：判据是 Windows 版本与 DWM 能力，
-/// 非 Windows 平台在这里恒得「直角」（平台没有可承诺的系统圆角）。
-pub use win32::corner::{plan_corner, CornerExclusion, CornerPlan, CornerSource};
+/// 窗口圆角的**判定**（M116 / M182）住在 `win32::corner`：判据是用户策略 × 宿主平台 × 渲染档。
+/// 非 Windows 的两档（macOS = 合成器不裁 borderless 窗、Linux = CSD 没人裁）在
+/// [`macos`] / [`linux`] 两个模块里逐条给了证据。
+pub use host::HostOs;
+pub use win32::corner::{plan_corner, plan_corner_for, CornerExclusion, CornerPlan, CornerSource};
 
 /// 本机 Windows 版本（`None` = 非 Windows / 读不到）。**进程内只探测一次**。
 ///