feat(判题机): 自建镜像升级工具链，语言收敛到 C / C++ / Python

上游 QingdaoU/JudgeServer 停更在 2024-04（registry 上的 latest 和 1.6.1 是同一份
镜像，编译器停在 gcc-13），没有新版可拉，所以自己重编。docker/judge/ 是只改工具链
的 Dockerfile 分叉，server/ 和 Judger/ 从上游固定 commit b28aa56 拉，一行没动。

镜像 oj2-judge-2（不在任何 registry 上：本机 build.sh --save → scp → docker load）
- gcc/g++ 13 → 14.2，Python 3.12 → 3.13.5，都是 trixie 默认
- Go / JDK / Node 整套删掉：前端的题目语言复选框从来只给 C / C++ / Python / SQL，
  12 万条提交里 Java 44 条、Golang 15、JavaScript 3，全是很早以前的
- 体积 1.1GB → 433MB；默认走清华源，构建 12 分钟 → 40 秒（--no-mirror 换回官方）
- deploy.sh 加一道自检：镜像不在本机就中止，并打印该跑的三条命令

C 的编译参数加三个 -Wno-error（implicit-function-declaration / int-conversion /
incompatible-pointer-types）：gcc-14 把它们从 warning 提成了 error，而 -w 压不住。

语言值统一成 Python（迁移 0019 / 0020）
- 0019：Python3（104527 条提交）与 Python2（3 条）并成 Python，一并改掉 937 道题的
  languages、75 个 template 键、15 个 ast_rules 键、257 条 answers、1235 个用户的
  成就指标 _languages（languages_used 重算，总和 1928 → 1925，少的 3 个是同时用过
  两种 Python 的人）
- 0020：把 Java / JavaScript / Golang 从 84 道题的可选语言里摘掉 —— 不摘的话那些题
  的语言下拉还能选 Java，提交必 SYSTEM_ERROR
- 契约新增 normalizeLanguage() 别名表，判题侧一律走 judgeConfigFor()：旧客户端
  localStorage 里的 Python3、迁移前排进队列的任务都还能判；协作的语言归一也走它，
  否则上线那一刻学生页面里的 Python3 会静默落到 C
- 回滚要连数据一起回，只滚代码会让所有 Python 提交变 SYSTEM_ERROR

实跑
- 判题冒烟 docker/judge/smoke.ts 13 条全过：三种语言、六种状态码、gcc 宽松度
- 拿备份里的真实代码逐文件比对新旧镜像的编译结果，0 差异：C 提交 1951 份
  （1725 过 / 226 CE）、C++ 882 份、Python 2000 份、20 篇 C 教程的 93 个代码块。
  不加那三个 -Wno-error 的话，C 有 26 份会从能过变成 CE
- 迁移在灌了 12.4 万行真实数据的一次性库里跑过：0 残留、没有题目被清空；
  dev 库用真正的执行器跑通
- check:ast 56 个 target 全过，前后端 typecheck 均 0

顺带记下一个升级之前就有的坑（现在随 Go 一起消失，写在 README 里）：GOCACHE 指向
容器的 tmpfs，判题机重启后第一次 Go 提交是冷构建，Go 1.22 要 5.6 秒 CPU、超过 3 秒
的编译预算，于是重启后第一个交 Go 的学生必吃一次 CE，后面的人缓存热了又都正常。

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

apps/api/src/db/schema.ts

@@ -858,11 +858,12 @@ export const submission = pgTable(
      * 提交列表的「语言」和「结果」两个下拉筛选。原来这两列上要么没索引、要么只有
      * 不带 `contest_id IS NULL` 的单列索引，翻页那条靠 submission_public_create_time_id_idx
      * 边扫边滤还能对付，**count 那条只能全表扫**（快照实测固定 75~82ms / 18448 buffers，
-     * 筛什么值都一样）。加完：语言 count 80ms → 11ms（Python3，占 8 成）/ 1.6ms（C），
+     * 筛什么值都一样）。加完：语言 count 80ms → 11ms（Python，占 8 成）/ 1.6ms（C），
      * 结果 count 75ms → 2.0ms。
      *
-     * 更要命的是冷门语言的**翻页**：Python2 只有 3 条、全是 2022 年的，分页索引得从
-     * 最新一路倒扫到底才凑够一页，43ms 全表扫；走这条索引是 0.02ms。
+     * 更要命的是冷门语言的**翻页**：JavaScript 只有 3 条、全是很早以前的，分页索引得从
+     * 最新一路倒扫到底才凑够一页，43ms 全表扫；走这条索引是 0.02ms。（这个实测当年用的
+     * 是 Python2，那 3 条 2026-09 已被 0019 迁移并进 Python，换了个同样冷门的值举例。）
      *
      * 两列都 ASC NULLS LAST，理由同上面 submission_public_create_time_id_idx ——
      * 靠 Index Scan **Backward** 出 `ORDER BY create_time DESC`。这里再实测了一遍：