保存链路：内核在线时跳过 mihomo -t，离线时写盘不再回滚

实测 mihomo -t 占整条保存链路九成以上耗时（4-9.4 秒），而 PUT /configs
自带同一套解析、失败时什么都不应用，配合既有的还原备份等于校验，重载
只要几十到几百毫秒。代价是写盘到还原之间的短暂窗口里磁盘上存在一份
可能有错的配置。

顺带修正离线行为：原来重载连不上会把刚写好的文件还原掉，但内核起不来
时用这个界面修配置正是核心场景，现在离线走 mihomo -t 校验后写盘不重载。

server/kernel.ts

@@ -54,8 +54,8 @@ export async function validateConfigFile(
  * 启动时先把内核二进制跑一次，什么都不做。
  *
  * `mihomo -t` 的第一次调用要 4 秒，之后 55 毫秒（在目标机器那种规格上实测差距只会更大）。
- * 差的是把这个几十兆的可执行文件读进系统文件缓存的时间，跟配置内容无关。不预热的话，
- * 这 4 秒会落在用户按下的第一次保存上，而那正是他最容易以为「这个工具很慢」的时刻。
+ * 差的是把这个几十兆的可执行文件读进系统文件缓存的时间，跟配置内容无关。现在只有内核
+ * 不在线时保存才走 `mihomo -t`，而那正是用户最着急的场景，这 4 秒不该落在他头上。
  *
  * 失败不用管：内核二进制不可用这件事，第一次真正校验时会带着完整错误信息报出来。
  */
@@ -95,6 +95,10 @@ export async function kernelVersion(env: Env): Promise<{ online: boolean; versio
 /**
  * 让内核重新加载配置文件，不重启进程。
  *
+ * 这一步同时就是校验：内核先完整解析，解析失败什么都不应用并返回 400，响应体是解析
+ * 错误原文（内核源码 hub/route/configs.go:430-438）。落盘链路在内核在线时靠它把关，
+ * 不再单独跑 `mihomo -t`。
+ *
  * `force=true` 意味着连端口这类需要重开监听的改动也一并生效——正是本项目改入站时需要的。
  * 注意 `path` 是**内核所在机器上的路径**：部署时 Patchbay 和内核在同一台机器上所以没有问题，
  * 但开发时如果 Patchbay 在本机、内核在远端，这个调用不会加载到本地的文件。