fix: P0 计分根因 + 奖牌结算/奖牌通道 + 身份口径改回证件号 + 19 条 P1（dev_0.1.8）

## P0：双通道项目重复发布跳分（45→85→收敛）
results.rank 一列同时充当「个人名次输出」「手工名次输入」「榜单数据源」，
团体手工通道把个人名次当团体名次又按团体表发一遍分。
- 新增 channel_ranks（每个计分通道各自持久化名次，发布时全量重建）
  与 channel_manual_ranks（按单位录入的团体手工名次，故意不挂通道外键，
  避免规则包重导时级联删掉录入数据）
- results.rank 语义收窄为「只表示个人名次」，只由 scope=athlete 通道写回；
  团体手工名次的来源改为 TeamRanks 优先、团体报名项兜底，
  个人报名项的名次绝不进团体通道
- writeLedgerTx 内重建 channel_ranks；buildRanked / export.loadRanked /
  realtime.loadRanked 三份同源 SQL 一起改读新表
- 回归：发布两次流水与名次逐字节一致（domain + httpapi 各一条，含变异验证）

## 奖牌结算开关与奖牌通道（P1(5)，新功能）
- events.award_medals + 通道 count_to_medals / count_to_team_medals
  （迁移默认 1，升级不改变既有榜单）
- 单位榜入选 = 小项结算奖牌 && 通道发奖牌 && 前三名 &&（团体项目 || 个人奖牌并入单位）
- 个人榜只取个人通道；金牌榜与积分榜同源同数据、按通道过滤独立计算
- 前端：小项「该项启用奖牌结算」、通道「发奖牌/个人奖牌并入单位金牌榜」、
  录入页新增「团体名次」区块（含新接口 GET/PUT .../team-ranks）

## 身份口径改回证件号（P1(15)，推翻第三十六轮）
- 匹配顺序恢复 证件号 → 号码布 → 姓名+单位；新增 athleteByIDCard
- 同表重复证件号 = 同一人报多个组别（notices 提示，不报错）；
  只有「同证件号 + 同小项同组别」才是真重复（conflicts[].duplicate）
- 补齐后端缺失但前端/文档已在依赖的三处契约

## 其余 P1
- 安全：会话撤销断开 ws、实时层按角色裁剪、整库快照限流（含 hello 路径，
  被限流的请求挂起并由心跳兜底补发，不丢刷新）
- 错误分级：手填名次非正数 / gender / 组别年龄 / 导出不存在的小项与单位 /
  积分模板 awardRanks → 400 或 404，不再 500
- 算分一致性：破纪录加分看得失状态；批量退赛·恢复·移出、作废成绩、
  报名导入改状态一律无条件重算推榜（不受延迟结算约束，与实时模式逐字节等价）
- 配置改动触发重算：通道 / 小项参数 / 积分模板
- 升级自愈：channel_ranks 空而已有已发布成绩时，启动时一次性全量重算
  （服务对外监听之前完成，避免升级后奖牌榜全 0）
- 示例数据模式下破坏性操作被阻断，不再假成功
- Console：修复「只剩一块屏」后屏幕监听器被永久摘掉
- 大屏模板引擎：嵌套深度与体积安全阀，任何输入都不抛异常

## 文档
- docs/：使用手册（奖牌开关、奖牌通道、团体名次、枚举列留空口径）、
  常见问题（奖牌排查、升级后奖牌榜为 0、历史重放已知限制）、
  部署指南、上线检查清单
- 版本 dev_0.1.7 → dev_0.1.8（console/package.json 同步）

自检：服务端 13 包 ×2 全绿；前端 vue-tsc + 449 例 ×2 + pnpm build；
Console 35 例 + 语法检查。

server/internal/realtime/client.go

@@ -33,25 +33,37 @@ type client struct {
 	userID        int64
 	sessionRole   string
 	sessionUserID int64
-	instanceID    string
+	// sessionID 是握手时的会话 id（未登录为空）：会话撤销后要据此复查并断开本连接。
+	sessionID  string
+	instanceID string
 	// settingsAdmin 表示会话是否为 admin：recorder 也进管理端房间，但读不到系统配置。
 	settingsAdmin bool
 
 	ackVersion atomic.Int64 // 客户端已确认应用到的版本
 	lastSent   atomic.Int64 // 服务端已发出的最大版本
-	slow       atomic.Bool
+	// snapshotAt 是本连接最近一次发出整库快照的时间（unix 纳秒）。
+	// 它是「整库快照窗口」的记账点：resync 与不带 lastVersion 的 hello 都会走到发快照，
+	// 两者共用一个窗口，不能靠交替发把限流绕过去。
+	snapshotAt atomic.Int64
+	// snapshotPending 表示「有请求要过整库快照，但被窗口挡下了」：
+	// 心跳循环会在窗口过后补发一份，见 flushPendingSnapshot。
+	// 不能把被挡下的请求直接丢掉——大屏收到它不认识的变更时会主动 resync，
+	// 丢了就可能让那块屏一直停在旧数据上，直到下一条变更到来。
+	snapshotPending atomic.Bool
+	slow            atomic.Bool
 }
 
-func newClient(h *Hub, conn *websocket.Conn, remoteAddr, sessionRole string, sessionUserID int64, settingsAdmin bool) *client {
+func newClient(h *Hub, conn *websocket.Conn, remoteAddr string, id wsIdentity) *client {
 	return &client{
 		hub:           h,
 		conn:          conn,
 		remoteAddr:    remoteAddr,
 		send:          make(chan []byte, defaultSendBuffer),
 		done:          make(chan struct{}),
-		sessionRole:   sessionRole,
-		sessionUserID: sessionUserID,
-		settingsAdmin: settingsAdmin,
+		sessionRole:   id.Role,
+		sessionUserID: id.UserID,
+		sessionID:     id.SessionID,
+		settingsAdmin: id.SettingsAdmin,
 	}
 }
 
@@ -85,6 +97,29 @@ func (c *client) sendEvent(event string, data any) bool {
 	return c.sendRaw(msg)
 }
 
+// allowSnapshot 按连接给「整库快照」记账：窗口内只放行一次。
+//
+// 触发整库快照的入口有两个（resync，以及不带 lastVersion 的 hello），它们共用这一个窗口：
+// 一条 15 字节的帧就是一次 DB 事务 + 8 条查询，而赛事库是单连接（SetMaxOpenConns(1)），
+// 快照读取还在全局发送锁里——不限流的话，一个写坏的客户端就能把库连接与所有人的推送一起堵住。
+// 窗口（defaultSnapshotMinInterval）比客户端自己的 3s 冷却短，正常客户端按自己的节奏回来时
+// 窗口已经过期，重连补齐行为因此不受影响。
+func (c *client) allowSnapshot(minInterval time.Duration) bool {
+	if minInterval <= 0 {
+		return true
+	}
+	now := time.Now().UnixNano()
+	for {
+		last := c.snapshotAt.Load()
+		if last != 0 && now-last < int64(minInterval) {
+			return false
+		}
+		if c.snapshotAt.CompareAndSwap(last, now) {
+			return true
+		}
+	}
+}
+
 func (c *client) sendRaw(msg []byte) bool {
 	select {
 	case <-c.done:
@@ -163,6 +198,7 @@ func (c *client) handleMessage(ctx context.Context, data []byte) {
 			c.hub.log.Debug("忽略 hello 之前的 resync", "remote", c.remoteAddr)
 			return
 		}
+		// 整库快照的限流统一在 sendInitial 里判定（resync 与重复 hello 共用同一个窗口）。
 		c.hub.sendInitial(ctx, c, nil)
 
 	default: