feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」

构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false），
cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传
（与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入
或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」，
不会拿空 id 去联网。

文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md /
packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量
ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。
client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写），
并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在
已烘焙 id 的构建里故意红。

实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出
用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。
单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、
在不带 id 的构建里绿。cargo fmt --all --check 通过。

crates/cli/src/cli/help.rs

@@ -133,10 +133,10 @@ accessToken 一律脱敏（输出里出现的是 <redacted:token>）。",
 **分文件**存放，先写凭据后写元数据、原子写、凭据文件 POSIX 侧 0600。
 凭据永不打印：list 只输出名称/轨道/UUID。
 add msa 走微软 device-code（用户码打在 stderr，去 https://www.microsoft.com/link 输码）。
-它需要一个 Azure 公共客户端 id —— 登录链路是完整的，缺的只是这一项配置；id 不进仓库：
-  ULL_MSA_CLIENT_ID=<id> %prog% accounts add msa    每次运行时给（环境变量优先）
-  ULL_MSA_CLIENT_ID=<id> cargo build               构建时注入，二进制自带
-两处都没有时命令立刻报「微软登录未配置」（含怎么配），**不会去联网**。
+微软登录所需配置已内置在官方构建里，装完即可用；仍可用环境变量覆盖（优先于内置值）：
+  ULL_MSA_CLIENT_ID=<id> %prog% accounts add msa    每次运行时给（优先于内置值）
+  ULL_MSA_CLIENT_ID=<id> cargo build               自己从源码构建时注入，二进制自带
+两处都没有时（只有自建且不自带 id 才会这样）命令立刻报「微软登录未配置」（含怎么配），**不会去联网**。
 authlib-injector 账户的密码登录留给 GUI（密码进 argv 会泄露，CLI 不开这条通道）。",
         ),
         "sessions" => Some("%prog% sessions list [--limit N]  列出会话索引（按开始时间倒序，缺省 20 条）"),

crates/core/src/auth/microsoft/client_id.rs

@@ -2,8 +2,9 @@
 //!
 //! ## 为什么单独一块（M117）
 //!
-//! 这个 id 不进仓库（用户定案），所以它可以来自两处：运行期环境变量 [`CLIENT_ID_ENV`]，
-//! 或构建期 `option_env!` 注入（[`CLIENT_ID_BUILD`]）。**两处都没有**时登录是「没配置」，
+//! 这是**公共客户端 id**（非机密，随二进制一起分发），可以来自两处：运行期环境变量 [`CLIENT_ID_ENV`]，
+//! 或构建期 `option_env!` 注入（[`CLIENT_ID_BUILD`]）——官方发布构建在构建时烘入它（M149），
+//! 所以官方产物开箱即用；环境变量仍优先，可覆盖。**两处都没有**时登录是「没配置」，
 //! 不是「没实现」——这两件事在用户眼里完全不同，文案与日志都必须分清：
 //!
 //! | 现象 | 该说什么 |
@@ -20,6 +21,9 @@
 pub const CLIENT_ID_ENV: &str = "ULL_MSA_CLIENT_ID";
 
 /// 构建期可注入的 client id（`ULL_MSA_CLIENT_ID=<id> cargo build`）。
+///
+/// 官方发布构建就是这么烘的（`.github/workflows/release-build.yml` 给构建步设了同名环境变量，M149；
+/// 值来自仓库 Secret，不进 git 文件），所以官方产物走到这里恒为 `Some`；从源码自建时才可能为空。
 pub const CLIENT_ID_BUILD: Option<&str> = option_env!("ULL_MSA_CLIENT_ID");
 
 /// 两处都没配时给用户看的那句话（CLI / GUI / 启动日志共用，**不含任何真实 id**）。
@@ -180,7 +184,10 @@ mod tests {
                 assert_eq!(message, MISSING_CLIENT_ID_MESSAGE);
                 assert!(!message.contains("未支持"));
             }
-            // 构建期注入过 id 时唯一合法（本仓库 CI/本地都不注入，走不到这里）。
+            // 构建期注入过 id 时唯一合法（`ULL_MSA_CLIENT_ID` 也设进 `cargo test` 的环境就会走到这里；
+            // 官方发布构建即烘了 id，但门禁里的 `cargo test` 不带该变量，故常态走上面那条。
+            // 注意：把该变量导出到跑测试的 shell 会让 presenter 的 M132 入口锚**故意红**
+            // （它要求「两处都没有 id」的构建，见 crates/presenter/src/host/accounts/tests.rs）。
             Ok(_) => assert!(
                 CLIENT_ID_BUILD.is_some_and(|value| !value.trim().is_empty()),
                 "没配 id 却构造成功"