feat(upstream): 上游更新检查——定期比上游、落后了推企业微信

本仓库在上游 MediaCrawler 之上加了一整层（见 UPSTREAM.md），可合并流程默认
「有人知道上游动了」。而部署是 git pull --ff-only，只从自己的 Gitea 拉——上游的
提交不主动 fetch 就永远看不见。拖着不合并的代价是复利的：越久越难合。

于是把「上游动了没有」变成一条会自己跑、会推企业微信的通知：

* api/monitor/upstream.py：git fetch <url> <branch> 到 FETCH_HEAD，用
  rev-list --count HEAD..FETCH_HEAD 算落后数、FETCH_HEAD..HEAD 算领先数。
  用 git 而非托管商 API，因为只有 git 知道共同祖先在哪——本仓库含有上游没有的
  提交，直接比 tip 会得出错误结论。增量 fetch 只传几个新提交，不会遇到
  UPSTREAM.md 里说的「大包必断」。
* 只 fetch 到 FETCH_HEAD：不配 remote、不写 refs/remotes、不碰索引与工作区，
  所以不打断正在跑的采集，也不和 deploy.sh 的 git pull 抢锁。
* 挂在调度器 tick 上（不是采集，所以不看 is_busy、不受活跃时段限制——定时检查
  放在半夜反而最合适），按 checked_at + 间隔 到期才跑；失败也写 checked_at，
  于是 GitHub 不通时是每间隔重试一次，而不是每个 tick 撞一次墙。
* 同一个 tip 只推一次（记 tip 而不是「推过没」），上游真又动了会再推。
* 两个接口：GET /monitor/upstream 只读缓存；POST /monitor/upstream/check 手动
  查一次且刻意不推通知——点按钮的人正看着结果。
* 默认关闭，间隔默认一天。

Dockerfile 显式装 git（python:slim 不带，而这是唯一的依赖）；deploy.sh 顺带补上
一个真 bug 的提示：Dockerfile/requirements.txt 变了只 up -d 用的还是旧镜像。

UPSTREAM.md

@@ -18,6 +18,7 @@ api/auth.py                          WebUI 登录鉴权
 api/monitor/*                        监控层整体（含 platforms.py 能力矩阵）
 api/monitor/db.py                    MySQL 连接层（可回退 SQLite 供测试用）
 api/monitor/migrate_from_sqlite.py   SQLite → MySQL 一次性迁移脚本
+api/monitor/upstream.py              上游更新检查（定时 fetch 上游并比对）
 api/routers/{auth,monitor,settings}.py
 api/schemas/{auth,monitor,settings}.py
 api/services/interpreter.py          解释器探测（uv / .venv / 当前解释器）
@@ -25,10 +26,14 @@ webui/src/components/{monitor,settings,auth}/    新视图
 webui/src/components/layout/{PlatformSwitcher,UnwiredPlatformNotice}.tsx
 webui/src/{hooks/useMonitor.ts,hooks/usePlatform.ts,store/platformStore.ts,lib/monitorFormat.ts,types/monitor.ts}
 docs/监控功能使用说明.md
-tests/test_{auth,settings,platforms,qrlogin,monitor_*}.py
+tests/test_{auth,settings,platforms,qrlogin,monitor_*,upstream}.py
 Dockerfile / .dockerignore / docker-compose.yml     服务器部署用
 ```
 
+> `api/monitor/upstream.py` 要调 `git`，而 `python:3.11-slim` 不带它 —— Dockerfile 里为此
+> **显式装了 git**。改了 Dockerfile 就必须重建镜像（`docker compose build`），`./deploy.sh`
+> 只重建前端，不重建镜像。
+
 其中 `api/monitor/qrlogin.py` + `webui/.../QrLoginPanel.tsx` 是**服务器专用**的扫码登录：
 那台机器上 Chrome 跑在 Xvfb 里，`show_qrcode` 调的 PIL `Image.show()` 需要桌面看图程序，
 服务器没有，二维码会无处可去。所以改成用 CDP 把二维码从页面里读出来交给前端 `<img>` 显示。
@@ -89,6 +94,16 @@ Dockerfile / .dockerignore / docker-compose.yml     服务器部署用
 
 ## 三、上游更新时怎么操作
 
+### 先让机器替你盯着
+
+「上游更新检查」（`api/monitor/upstream.py`，开关在 WebUI 的**系统设置 → 上游更新**）会按
+间隔 `git fetch` 上游、算出落后几个提交，有更新就推企业微信。它是这份文档的自动化版：
+没有它，「上游动了」这件事只取决于谁偶尔想起来去 fetch 一次。
+
+两个细节决定了它为什么是安全的：它只 fetch 到 `FETCH_HEAD`，**不写工作区、不建 remote、不碰
+`refs/remotes`**，所以和正在跑的采集、和下面的 `git pull` 都不冲突；默认**关闭**，因为要联网，
+且需要镜像里有 git。
+
 ### 日常流程
 
 ```bash