[Feature]: M5-2 Claude Desktop 写入适配器：4 文件组事务与恢复官方 #208

拆自 #203 的 M5（P1）。本 issue 负责写入适配器 + 4 文件组事务 + 恢复官方。依赖检测 issue（registry / inspect）先落地；模型名校验见配套 issue。

Problem to solve

检测能力就位后，需要真正把 Anthropic 协议 Provider 的配置写进 Claude Desktop。这个写入横跨 4 个文件，任何一步失败留下半成品都会破坏用户的客户端——securefs 的原子写只保证单文件，组级语义缺失。

同时必须守住 BootAgent 的既有承诺：只碰自己拥有的键，不动用户其他内容；能完整还原到官方模式。

Desired outcome

应用 Anthropic 协议 Profile 后，Claude Desktop 进入第三方模式并能用配置的 claude-* 模型对话；用户配置文件里其余键逐字节不动。一键恢复官方模式后，只摘除 BootAgent 自己的痕迹，用户自建的其他 profile 条目原样保留。任一步写入失败，4 个文件全部回滚到写前内容。

Proposed approach

新写入适配器（落在 internal/desktopapp 或 internal/config）：

• deploymentMode 读-改-写只碰这一个键（两个目录的 config 都要写）；
• configLibrary/<固定UUID>.json 写入 gateway profile（品牌名 BootAgent，固定 UUID 便于识别自有条目）：inferenceGatewayBaseUrl / inferenceGatewayApiKey / inferenceModels / inferenceProvider: "gateway"；
• _meta.json 只增删自己的条目，appliedId 移交逻辑对齐 cc-switch 语义；
• 恢复官方：deploymentMode=1p + 删自有 profile + meta 摘除；
• 4 文件组事务：写前快照，任一步失败全部回滚——在 securefs 原子写之上补一层组语义。

API key 写入 profile 文件属必需，但不得进入 DTO、界面回显与日志。

Acceptance criteria

1. 应用 Anthropic 协议 Profile 后：两个 claude_desktop_config.json 的 deploymentMode 为 3p，且其余键逐字节不动（fixture 断言）；profile 文件含正确的 base_url / key / 模型数组；_meta.json 仅多出自己一条。
2. 恢复官方：deploymentMode=1p、自有 profile 删除、meta 摘除自己，用户自建的其他 profile 条目原样保留（fixture 断言）。
3. 模拟 profile 写入失败 → 4 个文件全部回滚到写前内容（单测）。
4. API key 明文不出现在 DTO、界面、日志（对日志与 DTO 序列化做 grep 断言）。
5. 人工验收：重启 Claude Desktop 后模型菜单出现所配 claude-* 模型且能正常对话；结果（客户端版本号 + 截图）记入 PR。
6. 发布说明标注：该机制基于官方客户端未公开文档的行为，客户端更新可能失效。
7. 门禁：go test ./...、go test -race ./...、go vet ./...、frontend 全套全绿。
8. golden fixtures 先行（AGENTS.md 红线）：先写「期望落盘内容」再写实现。

Additional context

完整方案见 #203 与 docs/ux-and-agent-capability-optimization-plan.md §8。

依赖关系：需要检测 issue 的 inspect 提供「当前 profile 结构是否符合已知 schema」的判断——结构不符时拒写并提示，不硬写。

范围说明：只做直连模式。模型映射（在 Claude Desktop 里用非 Claude 模型）依赖本地代理，属 #203 非目标。

⚠️ 这是本方案里对用户环境侵入性最强的一项（改动第三方客户端的多个配置文件）。建议评审时重点看第 1、2、3 条验收的 fixture 设计。