refactor!: rename the project from Monitor to MoShiro

Namespaces, assemblies, projects and directories, the solution, binaries,
images, systemd units, config paths, environment variables, protocol method
names, the media type and the raw chunk magic all move to MoShiro/moshiro.
Existing data and deployments are not compatible and must be recreated.
Also fix the architecture tests after the solution layout change and make
the update tests independent of their order.

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. 产品接入一览