fix(ui,test): 说明巡检与重登的联动关系；修掉一条按分钟偶发失败的测试

看图时发现两个问题：

一、页面上那段说明是 P1a 时代的文案，已经过时且误导：「重登仍由人工在
「CK 检测与重登」页面操作」——P1b 上线后自动重登已存在。两个作业其实是联动的
上下游：巡检把账号标成 invalid，「CK 自动重登」的候选条件正是这个字段，所以
巡检一发现失效、重登作业下一周期就会接手。刻意分成两个作业是为了止损粒度
（巡检只读零风险；重登会真实登录，出问题可单独关掉）。据此改写说明文案，并在
两张卡片上标出「下游：CK 自动重登」/「上游：巡检标记为失效且有 CK 的账号」。

二、jobs 接口新增 pending_relogin：当前有多少条正等着自动重登。页面靠它把
上下游关系显性化 —— 没有这个数字，两个开关看起来像互不相干。计数走重登作业
自己的候选查询，保证「页面显示的待办」和「作业实际会捞的」是同一口径。

顺带修掉 tests/test_douyu_email_code_pick.py 里一条既有缺陷：它用
max(0, now.minute - 30) 构造「30 分钟前的邮件」，分钟数小于 30 时会退化成当前
整点（21:00:12 → "今天 21:00"），只比 now 早十几秒，于是断言随「当前几点」偶发
失败 —— 每小时前 30 分钟必红（已确认在我本次所有改动之前的提交上同样失败，
不是本次引入）。改成真实的时间减法，跨天时用「昨天」。

全量 298 通过。提交时另一路 SQLite→MySQL 的测试改造仍在同一工作区进行，
本次只暂存本功能相关文件。

web/backend/routers/automation.py

@@ -86,8 +86,21 @@ def list_jobs(
         db.query(AutomationRun).order_by(AutomationRun.id.desc()).limit(200).all()
     ):
         latest.setdefault(run.job_key, run)
+    # 巡检与重登是两个作业，但通过数据库联动：巡检把行标成 invalid，重登作业的
+    # 候选条件正是这个字段。这里把「当前有多少条等着重登」一并返回，页面才能把
+    # 这层上下游关系显示出来，而不是让人以为两个开关互不相干。
+    from ..services.automation.jobs.ck_relogin import build_select_query
+
+    pending_relogin = 0
+    relogin_job = next((job for job in jobs if job.key == "ck_relogin"), None)
+    if relogin_job is not None:
+        pending_relogin = build_select_query(
+            db, relogin_job, datetime.now(UTC), max_attempts=10**6
+        ).count()
+
     return {
         "scheduler": scheduler_status(),
+        "pending_relogin": pending_relogin,
         "jobs": [
             {
                 **_job_out(job),