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 通过。

README.md

@@ -83,16 +83,17 @@ Three tracks on one page:
 - **Third-party community auth servers** (authlib-injector style).
 - **Local offline profiles**, for isolated testing.
 
-**Microsoft sign-in needs an Azure public client id, and no release binary carries one.** The id is
-not in this repo and CI injects none, so set `ULL_MSA_CLIENT_ID=<id>` before launching, or build with
-it (`ULL_MSA_CLIENT_ID=<id> cargo build`, which bakes it in via `option_env!`). Without one, sign-in
-stops before any network call and the alert says exactly what is missing: the title "Microsoft
-sign-in is not configured", a body naming `ULL_MSA_CLIENT_ID=<id>` (set it, or build with it, then
-restart the launcher — a running process does not pick up a new variable), and
-`Code: msa_not_configured`. It offers no Retry button, because retrying in that same process cannot
-help. Every other sign-in failure keeps the older shape: one category line plus its own `Code:`
-line, with the full reason only in the launcher log. Community auth servers and local profiles need
-no id.
+**Microsoft sign-in works out of the box in official builds.** Release binaries carry the Azure public
+client id they need (a public client id, not a credential — it ships inside the binary), so there is
+nothing to configure before signing in. Setting `ULL_MSA_CLIENT_ID=<id>` still overrides it: the
+variable is read at startup, so restart the launcher after changing it. Building from source bakes in
+whatever that variable holds at build time (`ULL_MSA_CLIENT_ID=<id> cargo build`). A build with no id
+anywhere stops before any network call, and its alert says exactly what is missing: the title
+"Microsoft sign-in is not configured", a body naming `ULL_MSA_CLIENT_ID=<id>` (set it, or build with
+it, then restart), and `Code: msa_not_configured`. It offers no Retry button, because retrying in that
+same process cannot help. Every other sign-in failure keeps the older shape: one category line plus
+its own `Code:` line, with the full reason only in the launcher log. Community auth servers and local
+profiles need no id.
 
 ### Look and language
 
@@ -243,7 +244,7 @@ upstream cargo. On Linux, X11 is the preferred path today and Wayland is the lon
 Capability differences are feature gates with runtime probing, never a compile-time "this platform
 gets less".
 
-First run with a Microsoft account? Set `ULL_MSA_CLIENT_ID` first — see
+First run with a Microsoft account? Nothing to configure — official builds carry the client id; see
 [Accounts](#accounts). Nothing else needs configuring.
 
 ## Build from source
@@ -266,6 +267,9 @@ cargo deny check licenses bans sources                 # dependency licences (re
 
 What the build produces:
 
+- A build from source carries no Microsoft client id by default. Set `ULL_MSA_CLIENT_ID` at build time
+  to bake one in (`ULL_MSA_CLIENT_ID=<id> cargo build`); official release binaries already carry one
+  — see [Accounts](#accounts).
 - `unlucky-launcher-iced` — the GUI, and the CLI in the same file: it answers every subcommand listed
   above. `iced` is cargo's bin name, not a download name — `packaging/make_artifacts.py` stages that
   same build as `unlucky-launcher_<version>_<platform>_<arch>` and names the binary