修复删除定时任务后 crontab.list 残留导致订阅更新无法重新注册 (#3021)

* 修复删除定时任务后 crontab.list 未同步导致订阅更新无法重新注册脚本

crontab.list 作为数据库的文件镜像，其同步 setCrontab() 此前串行在尽力而为
的 gRPC addCron/delCron 调用之后：当调度 worker 重启等导致 gRPC 短暂不可用、
addCron/delCron reject 时，setCrontab() 会被跳过，crontab.list 与数据库脱节。
而 shell/update.sh 的 gen_list_repo() 将 crontab.list 作为"已有任务"真源，
于是订阅更新误判脚本已存在、跳过新增注册（前端再也看不到这些脚本）。

将 create/update/remove/disabled/enabled/autosave_crontab 中的 gRPC 调用改为
尽力而为（try/catch + 告警日志），保证 setCrontab() 总是执行；autosave_crontab
额外将 setCrontab 提前到 addCron 之前，确保启动/调度器重启时文件总是同步，
并避免 gRPC 失败导致应用启动崩溃。

调度器内存中的任务注册与 crontab.list/系统 crontab 同步是两个相互独立的关注点：
gRPC 失败时内存调度可能在调度器重启后由 autosave_crontab 重新注册，但文件同步
不应因此被阻断。修复后既有的 crontab.list 残留会在下次重启或任意增删改时自愈。

可能与 #2422（订阅更新重复添加任务）同根因。

* 过滤 delCron 中 scheduleStacks 的 null job

nodeSchedule.scheduleJob() 对无效 cron 表达式（如 "0 * /6 * * *"，
空格分开了 * /6）会返回 null，原代码原样存入 scheduleStacks 数组。
delCron 取消时对 null 调 cancel() 抛出 UNKNOWN 错误，导致 gRPC
handler 中断、HTTP 端 cronService.remove() 跳过 setCrontab()，
crontab.list 残留已删任务的记录，导致订阅更新时 gen_list_repo()
误判脚本已存在、不再重新注册。

过滤 null 并对每个 cancel 调用加 try/catch 容错。

back/schedule/delCron.ts

@@ -13,7 +13,20 @@ const delCron = (
         '[schedule][取消定时任务] 任务ID: %s',
         id,
       );
-      scheduleStacks.get(id)?.forEach(x => x.cancel());
+      // 过滤掉 nodeSchedule.scheduleJob() 对无效表达式返回的 null，
+      // 否则对 null 调 cancel() 会让整个取消流程抛出 UNKNOWN 错误，
+      // 进而导致 HTTP 端的 remove() 跳过 setCrontab()，造成 crontab.list 残留。
+      scheduleStacks.get(id)?.filter((x) => x != null).forEach((x) => {
+        try {
+          x.cancel();
+        } catch (error: any) {
+          Logger.warn(
+            '[schedule][取消任务失败] 任务ID: %s, 错误: %s',
+            id,
+            error?.message || error,
+          );
+        }
+      });
       scheduleStacks.delete(id);
     }
   }