refactor!: rename the project from Monitor to MoShiro [CI]

Namespaces, assemblies, solution, binaries, images, systemd units, config paths, environment variables, protocol methods and the Linux user are all renamed. Breaking: existing databases, node identities and installed units must be recreated.

docs/fleet/overview.md

@@ -1,8 +1,8 @@
 # Fleet：通用节点框架
 
-> **实现状态**：`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计；容器节点的更新目前由宿主机上的 `monitor-update` 脚本和 Monitor 的 `ReleaseService` 完成（见 [deployment.md](../deployment.md)）。其余组件已实现。
+> **实现状态**：`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计；容器节点的更新目前由宿主机上的 `moshiro-update` 脚本和 MoShiro 的 `ReleaseService` 完成（见 [deployment.md](../deployment.md)）。其余组件已实现。
 
-> 名称暂定。Fleet 与业务无关，Monitor 是它的第一个使用者。
+> 名称暂定。Fleet 与业务无关，MoShiro 是它的第一个使用者。
 
 ## 1. 定位
 
@@ -10,7 +10,7 @@
 
 ```text
 ┌──────────────────────────── 产品层（各产品自己写） ─────────────────────────────┐
-│ Monitor：  Protocol(Kind/任务) · Measurement(积木) · Agent · Probe · Backend     │
+│ MoShiro：  Protocol(Kind/任务) · Measurement(积木) · Agent · Probe · Backend     │
 │ 其他产品：  YourApp.Node · YourApp.Server                                        │
 └──────────────────────────────────┬─────────────────────────────────────────────┘
                                    │ 只依赖 Fleet；Fleet 不认识任何产品
@@ -29,14 +29,14 @@
 
 ## 2. 设计原则
 
-1. **与业务无关**：Fleet 中不出现任何产品概念。产品通过扩展点接入：元数据类型、RPC 方法、发件箱消息类型、期望状态文档类型。`scripts/check-deps` 强制规定 `backend/fleet/**` 不能引用 `Monitor.*`。
+1. **与业务无关**：Fleet 中不出现任何产品概念。产品通过扩展点接入：元数据类型、RPC 方法、发件箱消息类型、期望状态文档类型。`scripts/check-deps` 强制规定 `backend/fleet/**` 不能引用 `MoShiro.*`。
 2. **安全默认值**：
    - Fleet **永远不提供** exec、shell、文件读写、远程下发代码这类方法；
    - 节点只响应本地注册过的方法，本地策略 `allow_methods` 还可以进一步收窄；
    - 更新必须通过离线密钥签名验证，面板即使被攻破也推不出恶意二进制。
 3. **权限分离**：注册（`fleet-enroll`，一次性运行）、常驻业务进程、更新（`fleet-updater`）是三个独立的进程，使用不同的系统用户，各自只拥有最小权限。
 4. **NativeAOT 优先**：节点侧只依赖 BCL；泛型扩展点通过产品传入的 `JsonTypeInfo<T>` 实现序列化，不使用反射。
-5. **只抽取真正用到的**：每项能力都必须同时被 Monitor 和 `samples/EchoNode` 使用，防止过度设计。
+5. **只抽取真正用到的**：每项能力都必须同时被 MoShiro 和 `samples/EchoNode` 使用，防止过度设计。
 
 ## 3. 组件
 
@@ -67,15 +67,15 @@ fleet/                              以后可以原样拆成独立仓库并发
 │  ├─ Fleet.Enrollment.Client/
 │  └─ Fleet.Server.Enrollment/  Fleet.Server.Link/  Fleet.Server.Releases/  Fleet.Server.Sqlite/
 ├─ tools/  fleet-enroll/  fleet-updater/  fleet-release/
-├─ samples/  EchoNode/  EchoServer/   最小示例：不依赖 Monitor 的第二个使用者
+├─ samples/  EchoNode/  EchoServer/   最小示例：不依赖 MoShiro 的第二个使用者
 ├─ tests/
 └─ docs → 仓库 docs/fleet/
 ```
 
 ## 5. 演进策略
 
-- **现阶段**（已确认，暂不独立）：放在 monitor 仓库的 `backend/fleet/` 目录中，通过项目引用使用，一处修改两边同时编译。
-- **拆分条件**：公开 API 连续两个里程碑没有破坏性变更，并且 `samples` 能覆盖全部能力。满足后拆成独立仓库，按 semver 发布 NuGet 包，Monitor 改为包引用。
+- **现阶段**（已确认，暂不独立）：放在 MoShiro 仓库的 `backend/fleet/` 目录中，通过项目引用使用，一处修改两边同时编译。
+- **拆分条件**：公开 API 连续两个里程碑没有破坏性变更，并且 `samples` 能覆盖全部能力。满足后拆成独立仓库，按 semver 发布 NuGet 包，MoShiro 改为包引用。
 - **公开 API 审查**：`backend/fleet/src/*` 的 public 类型使用 `PublicAPI.Shipped.txt` / `PublicAPI.Unshipped.txt` 跟踪（使用 `Microsoft.CodeAnalysis.PublicApiAnalyzers`，只在构建期生效），任何变更都会在 PR 中显示出来。
 
 ## 6. 产品接入一览