fix(achievement): 指标的 AC 口径改用 is_accepted，与全项目一致

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

docs/superpowers/plans/2026-08-03-achievement-system.md

@@ -18,6 +18,7 @@
 - 后端 lint：`ruff check .` 与 `ruff format .`（E/F/I 规则，行宽 180，双引号）。每次提交前必须通过。
 - 前端格式化：`npm fmt`（Prettier）。
 - 所有基于提交的指标**只统计 `contest_id IS NULL` 的提交**，比赛题不计入成就。唯一例外是 `contest_joined`。
+- **判断提交是否算通过一律用 `submission.models.is_accepted()`**，即 `result in (ACCEPTED, AST_CHECK_FAILED)`，与项目其余所有 AC 统计口径一致。ORM 过滤用 `result__in=(JudgeStatus.ACCEPTED, JudgeStatus.AST_CHECK_FAILED)`。（Task 2 执行期间由 reviewer 发现计划原文写成了 `result == ACCEPTED`，经人工裁决改正。）
 - 成就为纯荣誉，**不发放任何可消费奖励**，不接入积分/道具/权限体系。
 - 判定任务内所有异常必须捕获并记日志，绝不允许影响判题结果。
 - 指标未产生过有效值时，其 key **不存在于** `metrics` 字典中（而非置 0）。判定时遇到缺失 key 直接跳过该成就。

docs/superpowers/specs/2026-08-03-achievement-system-design.md

@@ -148,6 +148,14 @@ class MidnightSubmissions:
 
 这条对所有指标统一适用，累积型指标（缺失即视为未达标）行为不变，极小值型指标由此被正确保护。前端进度条同理：指标缺失时显示 `0 / N` 而不是拿缺失值参与计算。
 
+### AC 的口径
+
+判断一次提交是否算通过，一律使用 `submission/models.py` 的 `is_accepted()`，即 `result in (ACCEPTED, AST_CHECK_FAILED)`。
+
+`AST_CHECK_FAILED`（状态码 10）表示测试用例全部通过、但违反了教师配置的代码结构规则。项目里每一处统计 AC 的地方都把它算作通过（个人主页的已通过题数、题目的通过人数、比赛排名等），成就必须跟随同一口径——否则学生个人主页显示「已通过 50 题」而成就进度条显示 47，会被当成 bug 来问。
+
+ORM 过滤无法调用该函数，用 `result__in=(JudgeStatus.ACCEPTED, JudgeStatus.AST_CHECK_FAILED)`。
+
 ### 比赛提交不计入成就
 
 **所有基于提交的指标只统计 `contest_id IS NULL` 的提交。** 比赛里做的题不算进「AC 100 题」这类成就。