refactor(account): S2 读写一次切换 —— CK/健康/重登彻底搬到账号，登录记录退化为历史

S1 加好了列，本提交把**读与写一起切**过去。这是设计里「同一份数据的读与写必须
在同一个提交里切」的要求：先切读或先切写都会出现「写账号、读记录」的中间态，
跑起来不报错，只是默默用错数据。

## 核心改动

**判定「谁有 CK」不再借道登录记录**
- `cookie_holding_filter()` / `cookie_operable_filter()` / `cookie_holding_account_ids_query()`
  / `visible_douyu_task_accounts()` 全部改为作用于 `Account`；
- `cookie_operable_filter()` 的「在途排除」仍查 `login_tasks`（那是**某次尝试**的属性），
  用 `NOT EXISTS` 子查询 + 迁移 0042 新增的 `(account_id, attempt_status)` 索引；
- 删除死代码 `latest_cookie_login_task()`；`latest_cookie()` 改为直接读账号。

**CK 写入**
- `_write_login_success()` 写 `Account.cookie / cookie_updated_at / cookie_source`；
- `_mark_attempt_failed()` 改看**账号**有没有 CK（决定是否沿用旧的失败语义）；
- 检测模式的 `task.cookie = ""` **不再清空账号的 CK**（见下「行为变更」）。

**自动化作业按账号调度**
- `ck_health`：`_select_tasks` → `_select_accounts`，`db.query(Account)`；新增
  `count_remaining()`（刻意不带 LIMIT，否则积压数恒等于批次上限）；
- `ck_relogin`：同样按账号选行；结算改为「账号 + 本轮尝试记录」，
  退避进度写账号；`settle_fresh_results(batch_id)` 按 `attempt_batch_id` 配对，
  `run_ck_relogin` 把 **account_ids** 交给 runner；
- 顺带让**没有任何登录历史的账号**也能被巡检/重登（以前它们永远进不了队列）。

**登录批次**
- `LoginBatchRunner` 去掉 `relogin_task_ids`，重登与登录统一走 `account_ids`；
- 批次行复用逻辑重写：只保证「同一账号不并发两行」，不再关心「哪一行持有 CK」。
  失败行复用同时看 `attempt_status`（账号有 CK 时 `_mark_attempt_failed` 刻意不动
  `status`，只看 status 会永远命不中 → 每次失败刷一行）。

**删除护栏语义变更（用户可感知）**
- 去掉「持有 CK 的记录不可删」——CK 在账号上，删历史不再影响登录态，历史终于可清理；
- **保留**「在途尝试不可删」（批次线程正拿着那条记录）。

## 行为变更（需评审）

1. **账号检测不再清空 CK**。旧代码在 check 模式写 `task.cookie = ""`，而那时记录的
   cookie 就是账号唯一凭证 —— 一次「批量检测」会把账号登录态删掉。解耦后
   「检测账号凭据」与「CK 是否有效」本就是两件事（后者归 `ck_health` 判），
   继续清空等于凭空制造不可逆的数据丢失（重登当前成功率极低）。
2. **Cookie 页的记录单位从「登录记录」变成「账号」**，所有接口的 id 入参/出参
   变成 `account_id`；`DELETE /cookies/{id}` 清的是该账号的 CK，**必写审计**。
3. 重复检测从「同一账号多行持 CK」改为「**同一个 CK 出现在多个账号上**」——
   后者才是真风险（两个账号共用一个登录态）。用 sha256 指纹分组：
   CK 是 AES-GCM + 随机 nonce 加密，**同一明文每次密文都不同**，比密文永远比不出重复。

## 修掉一个真实并发缺陷

`_write_login_success` 原先被传入 `self.db`（runner 主会话），而它是在**工作线程**里
用 `worker_db` 执行的。`emit()` 会往 `account_events` 插一行，其 `account_id` 外键对
`accounts` 那一行加**共享锁**；这把锁加在另一个会话上，紧接着本会话的
`UPDATE accounts SET cookie=...` 就被自己人挡住 —— 实测 **50 秒后
`Lock wait timeout exceeded`，登录明明成功却写不回 CK**（改造前 UPDATE 打在
`login_tasks` 上所以没撞上）。改为传 `worker_db`：事件本就该和状态变更同事务提交，
顺带修掉跨线程共用一个 Session 的隐患。

## 验证

- 全量 pytest **368 passed / 6 skipped**；迁移链 3 passed；
- 前端 `tsc -b && vite build` 通过；
- `ruff check` / `ruff format --check` 全绿（顺带修掉 main 上遗留的 F821）；
- 新增/改写的关键回归：**删掉全部登录历史后账号的 CK 与健康状态仍在**、
  **无登录历史的账号也能进巡检队列**、结算不碰 CK、删除护栏改为在途语义。

仍未做（设计里排期的后续阶段）：`account_lifecycle` 状态收口（S3）、事件发射点补齐（S4）、
业务事实直发事件（S5）、账号页重构（S6）。注意 `status` 目前只有模型默认值与迁移回填，
所以 `disabled/archived` 还没有任何写入方——S3 落地时要把自动化选行的状态过滤一起补上。

web/backend/services/douyu_service.py

@@ -183,69 +183,63 @@ def ensure_douyu_config(db: Session) -> DouyuConfig:
     return config
 
 
-# 登录/重登尝试的在途状态：判断只看 attempt_*，与记录持有的 CK 无关。
+# 登录/重登尝试的在途状态：判断只看 attempt_*，与账号持有的 CK 无关。
 LOGIN_ATTEMPT_IN_FLIGHT_STATUSES = ("pending", "running")
 
 
 def cookie_holding_filter():
-    """判定登录记录当前是否仍持有 Cookie。
+    """判定**账号**当前是否持有 CK。
 
-    账号是否有 CK 只取决于记录里是否还留着 Cookie。登录尝试（attempt_*）
-    在成功前不会碰 status/cookie/message，所以停止、失败、进程重启都不会
-    让账号失去 CK；只有 Cookie 真正被清空（账号检测成功）时才不再持有。
+    CK 是账号级凭证（2026-10-04 起从 `login_tasks.cookie` 迁到 `accounts.cookie`）。
+    判定只看账号自己，不再看任何登录记录的状态 —— 这正是解耦的目的：
+    删历史、批次排队、重登失败都不该让账号凭空「没有 CK」。
     """
     return and_(
-        LoginTask.cookie.isnot(None),
-        LoginTask.cookie != "",
-    )
-
-
-def latest_cookie_login_task(db: Session, account_id: int) -> LoginTask | None:
-    """读取账号最近一条仍持有 Cookie 的登录记录。"""
-    return (
-        db.query(LoginTask)
-        .filter(
-            LoginTask.account_id == account_id,
-            cookie_holding_filter(),
-        )
-        .order_by(LoginTask.id.desc())
-        .first()
+        Account.cookie.isnot(None),
+        Account.cookie != "",
     )
 
 
 def cookie_operable_filter():
-    """判定登录记录能否基于现有 Cookie 再做检测或重登。
+    """判定**账号**能否基于现有 CK 再做检测或重登。
 
-    正在被批次处理的记录（attempt_* 处于在途状态）已由批次接管，并发再点
-    检测或重登只会互相覆盖，因此排除在外；CK 与 status 不参与判断。
+    在途排除仍然要查 `login_tasks`：「正被批次处理」是**某次尝试**的属性，
+    CK 才是账号的属性。所以这里是「账号有 CK」+「该账号没有在途尝试」。
+
+    走 `login_tasks(account_id, attempt_status)` 索引（迁移 0042 新增），
+    否则每轮选行都要回表。
     """
-    return and_(
-        cookie_holding_filter(),
-        func.coalesce(LoginTask.attempt_status, "").notin_(
-            LOGIN_ATTEMPT_IN_FLIGHT_STATUSES
-        ),
+    in_flight = (
+        select(LoginTask.id)
+        .where(LoginTask.account_id == Account.id)
+        .where(
+            func.coalesce(LoginTask.attempt_status, "").in_(
+                LOGIN_ATTEMPT_IN_FLIGHT_STATUSES
+            )
+        )
+        .exists()
     )
+    return and_(cookie_holding_filter(), ~in_flight)
 
 
 def latest_cookie(db: Session, account_id: int) -> str:
-    """读取账号当前 Cookie。"""
-    task = latest_cookie_login_task(db, account_id)
-    return task.cookie if task else ""
+    """读取账号当前 CK。"""
+    account = db.query(Account.cookie).filter(Account.id == account_id).first()
+    return (account[0] if account else "") or ""
 
 
 def cookie_holding_account_ids_query(db: Session):
-    """返回当前仍持有 Cookie 的斗鱼账号 ID 查询。"""
-    return db.query(LoginTask.account_id).filter(cookie_holding_filter()).distinct()
+    """返回当前仍持有 CK 的斗鱼账号 ID 查询。"""
+    return db.query(Account.id).filter(cookie_holding_filter())
 
 
 def visible_douyu_task_accounts(db: Session, account_ids: list[int]) -> list[Account]:
-    """只保留当前仍持有 Cookie 的斗鱼账号。"""
+    """只保留当前仍持有 CK 的斗鱼账号。"""
     if not account_ids:
         return []
-    cookie_ids = select(LoginTask.account_id).where(cookie_holding_filter())
     return (
         db.query(Account)
-        .filter(Account.id.in_(account_ids), Account.id.in_(cookie_ids))
+        .filter(Account.id.in_(account_ids), cookie_holding_filter())
         .all()
     )