refactor(契约): 出参不再 parse，后台老题详情和站内信页不再 500

## 出参改 satisfies

出参是后端自己刚拼出来的字面量，TS 编译期已经验过；再 xxxSchema.parse({...}) 一遍
拿不到任何新信息，唯一可能失败的输入是库里的历史数据，而失败的代价是 500。136 处
全部撤掉，撤的时候当场炸出两个一直存在的线上故障：

- 后台打开任何一道没编辑过的题都是 500 —— problem.last_update_time 是全库唯一可空
  的列（961 道题里 470 道是 NULL），而 adminProblemSchema.lastUpdateTime 写的是
  z.string()；
- 收到过站内信的人打开消息页全是 500 —— embeddedSubmissionSchema 从
  submissionDetailSchema 继承了 problemDisplayId 却没 omit，路由只填了同义的
  problem；列表为空时才碰巧不炸，所以一直没人报。

两个都是读出侧校验自己造出来的故障，不是它拦住的故障。

## 校验责任挪回写入侧

- db/schema.ts：枚举型的列和几个形状确定的 JSONB 挂 .$type<>()（submission.result /
  .language、problem.difficulty / .languages / .template / .astRules / .sqlConfig /
  .sqlDisplay、achievement.rarity / .operator、exercise.type、reaction.type、
  tutorial.type、problemset.difficulty / .status、flowchart_submission.status、
  problemset_badge.condition_type、acm_contest_rank.submission_info）。只影响 TS、
  不产生 SQL，断言逐列拿根目录那份生产备份核过全量数据。
- createProblemRequestSchema.languages 收窄成 problemLanguageSchema，兑现
  problem.languages 列上的断言。
- 新增 routes/helpers.ts 的 asFilterValue()：query 筛选值（result / language /
  difficulty / status）要和收窄过的列比较时做纯类型交接，不加校验 —— 在这儿拦一道
  会把「筛出空列表」变成「筛条件被忽略、返回全部」。
- 判题产物（submission.info / statistic_info / exercise.data）照旧放行，形状真相
  在判题机那边；judge/sql、flowchart/run、events.ts 里对自家产物的 parse 一并撤掉。
- 仍然 parse 的只有 judge/events.ts 的 parseSubmissionEvent —— 从 Redis 收回来的
  报文是真边界，失败返回 null 而不是 500。

顺带清掉两处重复的真相：stringArray 原本在 routes/helpers.ts、routes/problem.ts、
routes/submission.ts 各有一份拷贝，5 个调用点全部只作用于 problem.languages，列有类型后
三份一起删；routes/site.ts 里和契约同名同形的本地 interface Quote 也删了 —— loadSentences
读入时已经逐字段守过，那处 parse 同样是多余的。

## 文档

CLAUDE.md 那一节从「契约收紧要挑地方」改写成「出参不 parse，用 satisfies」，写明
三处写入侧闸门（入参 safeParse 58 处、列上 $type、语义校验函数）；apps/web/CLAUDE.md
同步 —— 现在收紧字段的后果落在 tsc 编译期，但契约形状仍要对得上存量数据。

## 验证

- 生产备份全量：12.4 万条提交的 result 全在 -2..6,10、961 道题的 languages 均为合法
  数组、10050 条榜单条目形状全对，无一例外；
- tsc -p apps/api 与 vue-tsc --noEmit 均 exit 0；check:routes 检查 177 条路由，无遮蔽；
  前端 build、单二进制编译并在仓库目录之外启动均通过；
- 实跑 40+ 端点（学生端 / 后台 / AI / 榜单 / 题目回写往返），以及一次完整比赛 e2e：
  建比赛 → 复制题目 → 错解 → 正解，把 judge/run.ts 榜单写入的三个分支全走到
  （error_number 0→1、is_first_ac + ac_time 671、totalTime 1871 = 671 + 1×20×60），
  后台核查页的勾选与 404 分支一并验过，测试数据已清理；
- 两个 500 用抓到的真实响应对着改动前的契约复验：lastUpdateTime 收到 null、
  problemDisplayId 收到 undefined，改动后同样两个响应均通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH

packages/contract/src/admin.ts

@@ -6,6 +6,7 @@ import { achievementRaritySchema } from "./achievement"
 import { rankProfileSchema } from "./account"
 import { paginatedSchema, sampleUserSchema } from "./common"
 import { reactionKeySchema } from "./content"
+import { problemLanguageSchema } from "./language"
 import {
   astRulesSchema,
   problemDifficultySchema,
@@ -671,7 +672,12 @@ export const adminProblemSchema = z.object({
   languages: z.array(z.string()),
   template: z.record(z.string(), z.string()),
   createTime: z.string(),
-  lastUpdateTime: z.string(),
+  /**
+   * `problem.last_update_time` 是全库唯一可空的那一列（961 道题里 470 道是 NULL：
+   * 从来没被编辑过的老题）。公共的 problemDetailSchema 早就是 nullable，这里漏了，
+   * 于是后台打开任何一道没编辑过的题都会 500 在 parse 上。
+   */
+  lastUpdateTime: z.string().nullable(),
   timeLimit: z.number().int(),
   memoryLimit: z.number().int(),
   visible: z.boolean(),
@@ -718,7 +724,9 @@ export const createProblemRequestSchema = z.object({
   testCaseScore: z.array(problemTestCaseScoreSchema),
   timeLimit: z.number().int().min(1).max(1000 * 60),
   memoryLimit: z.number().int().min(1).max(1024),
-  languages: z.array(z.string()).min(1),
+  // 收窄到语言联合而不是裸 string[]：`problem.languages` 列上挂着
+  // `$type<ProblemLanguage[]>()`，那个断言得有人兑现 —— 闸就设在这里（写入侧）。
+  languages: z.array(problemLanguageSchema).min(1),
   template: z.record(z.string(), z.string()),
   visible: z.boolean(),
   difficulty: z.enum(["Low", "Mid", "High"]),

packages/contract/src/submission.ts

@@ -149,7 +149,10 @@ export const submissionDetailSchema = z.object({
  * 将来有人「顺手」把空值改成真值就不会变成泄露，因为这里压根没有这些字段。
  */
 export const embeddedSubmissionSchema = submissionDetailSchema
-  .omit({ info: true, contestId: true, problemId: true })
+  // problemDisplayId 也要去掉：下面的 problem 就是它，同一个值留两份，
+  // 而路由只填了 problem —— 这里漏 omit 的那阵子，凡是收到过站内信的人
+  // 打开消息页都是 500（parse 抛在缺失的 problemDisplayId 上，列表为空时才碰巧不炸）。
+  .omit({ info: true, contestId: true, problemId: true, problemDisplayId: true })
   // 旧 SubmissionSafeModelSerializer 里 problem 是
   // `SlugRelatedField(slug_field="_id")`，即**展示用题号**而非数字主键。
   // 站内信页面拿它拼 `/problem/<题号>` 链接，给数字 id 会拼出打不开的地址。