chore(部署): push 后先过检查再部署；判题机重启那几秒交的题不再变成系统错误；worker 挂了看得出来

按外部分析报告（reports/analysis）挑出来做的几条：
- CI 在编完前端之后跑 `bunx vp run verify`，有一项不过就不部署（必须排在编前端之后：
  前端类型检查要的 auto-imports.d.ts / components.d.ts 是 vite build 时才生成的）
- 连不上判题机（连接被拒、解析不到、被重置）时，正式判题等 2/5/10 秒重试，不再当场记成
  系统错误；超时、判题机回错、页面上的运行和自测不重试
- worker 每 10 秒刷一次「还活着」，compose 加 `oj2-api healthcheck --worker`，deploy.sh 起栈后
  也等 worker 健康（docker 不会因 unhealthy 自动重启，只是看得见、部署时拦得住）
- 三套 compose 的容器日志限 10MB × 3
- `/public/%` 这类畸形编码回 404 而不是 500；找不到的接口回统一的 JSON 错误
- 删掉没人用的「停用判题机」接口，契约不再给 task_number / is_disabled（列留在库里）
- 删掉腐化的 apps/web/tests/submitButtonState.test.ts；契约包 zod 范围对齐到 ^4.6.6
- 修几处和实际对不上的注释与文档（表数、编译并发、AST 语言数、deploy.sh 流程、校验处数）

⚠️ 改了 compose 的日志配置，这次部署会把 postgres / redis / 判题机也重建一遍，各停几秒

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docker/compose.debian.yml

@@ -11,8 +11,17 @@
 # 不设它的话 postgres 会在空目录上初始化一个全新的空库，测试点和题面图片也全都不在，
 # 而且**不报错**。`deploy.sh` 为此专门设了自检。
 
+# 每个容器的日志最多 3 个 10MB 的文件。docker 默认的 json-file 不设上限，判题、worker
+# 天天打日志，2 核小服务器的磁盘迟早被写满 —— 磁盘一满，postgres 写不进、判题跟着失败。
+x-logging: &logging
+  driver: json-file
+  options:
+    max-size: 10m
+    max-file: '3'
+
 services:
   oj-postgres:
+    logging: *logging
     image: postgres:18-alpine
     container_name: oj-postgres
     restart: always
@@ -67,6 +76,7 @@ services:
       retries: 10
 
   oj-redis:
+    logging: *logging
     image: redis:8-alpine
     container_name: oj-redis
     restart: always
@@ -87,6 +97,7 @@ services:
       retries: 10
 
   oj-judge:
+    logging: *logging
     # 自己构建的判题沙箱（go-judge + gcc / python，见 docker/judge/）。
     # ⚠️ 这个 tag 不在任何 registry 上：本机 docker/judge/build.sh 构建，
     #    服务器/机房用 docker load 装。镜像不在本地时 compose 会去 pull 然后报找不到。
@@ -102,12 +113,13 @@ services:
       - ${DATA_DIR:-../data}/backend/test_case:/test_case:ro
     environment:
       ES_AUTH_TOKEN: ${OJ2_JUDGE_TOKEN:?请在 docker/.env 里设置 OJ2_JUDGE_TOKEN}
-    # 同一时刻最多六份在编译（正式判题 2、试运行 2、提交前编译检查 2），g++ 编一份 iostream
+    # 同一时刻最多四份在编译（judge/slots.ts 两个名额池：正式判题 2、学生页面上的运行和编译检查 2），g++ 编一份 iostream
     # 峰值约 70MB、bits/stdc++.h 约 195MB，再加学生程序本身。512m 不够撑满，超了是容器里
     # 随机杀进程、学生看到系统错误
     mem_limit: 1g
 
   oj-api:
+    logging: *logging
     build: &build
       context: ..
       dockerfile: docker/Dockerfile
@@ -149,6 +161,7 @@ services:
     cpu_shares: 2048
 
   oj-worker:
+    logging: *logging
     build: *build
     image: oj2-api:latest
     container_name: oj-worker
@@ -160,10 +173,19 @@ services:
     environment: *api-env
     # 同一个镜像，换个子命令就是判题消费者
     command: ["oj2-api", "worker"]
+    # worker 每 10 秒刷一次「还活着」，60 秒没刷就是挂了（oj2-api healthcheck --worker）。
+    # unhealthy 只是标出来、deploy.sh 起栈时会等它，docker 不会因此自动重启容器
+    healthcheck:
+      test: ["CMD", "oj2-api", "healthcheck", "--worker"]
+      interval: 30s
+      timeout: 3s
+      retries: 3
+      start_period: 20s
     # SQL 判题的子进程各允许 512MB 数据段（judge/sql 的 ulimit -d），两个并发就能顶满 512m
     mem_limit: 1g
 
   oj-web:
+    logging: *logging
     build:
       context: ..
       dockerfile: docker/Dockerfile