perf(判题): SQL 题每次判题少等约 50ms，后端起服务快一倍

单二进制改用预编译字节码（--bytecode --format=esm）。SQL 判题每题都要起一次子进程，
单核实测从约 120ms 降到约 72ms；serve 起服务约 180ms → 100ms，内存不变，二进制大 8MB。
编译形态在仓库外实跑过：migrate / healthcheck / serve / worker 能起，C 题判对、
AST 规则判出 10、jieba 分词、SQL 子进程的判题与展示都和 dev 形态结果一致。

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

apps/api/CLAUDE.md

@@ -15,6 +15,10 @@ OJ2 的后端（`apps/api`）。这里只放后端专属的坑；全仓通用的
 
 **改完这类代码，dev 和编译两种形态都要跑一遍。** 我吃过亏：只验了编译产物，dev 直接起不来。
 
+`build` 带 `--bytecode --format=esm`：每道 SQL 题都要起一次 `sql-child`，预编译字节码让它
+从约 120ms 降到约 72ms（单核实测），`serve` 起服务从约 180ms 降到约 100ms，内存不变，
+代价是二进制大 8MB。去掉 `--format=esm` 会退回 CJS 输出，顶层 await 编不过。
+
 ## 路径解析看 `runtime.ts`
 
 编译后 `import.meta.dir` 恒为 `/$bunfs/root`，往上三级就是文件系统根。

apps/api/package.json

@@ -9,7 +9,7 @@
     "dev:worker": "bun --watch src/main.ts worker",
     "start": "bun src/main.ts serve",
     "worker": "bun src/main.ts worker",
-    "build": "bun build --compile --target=bun-linux-x64 src/main.ts --outfile ../../dist/oj2-api",
+    "build": "bun build --compile --bytecode --format=esm --target=bun-linux-x64 src/main.ts --outfile ../../dist/oj2-api",
     "seed:dev": "bun src/scripts/seed-dev.ts",
     "recount": "bun --env-file=../../.env src/main.ts recount",
     "rediagnose": "bun --env-file=../../.env src/main.ts rediagnose",