refactor: 本地文件 IO 归位——重活留线程、微秒级直接同步，移除零使用依赖 aiofiles

为什么：文件 IO 这条线上 to_thread 用得过宽。凡是「单文件 exists / unlink / stat」
这类微秒级元数据操作，线程调度开销（几十微秒起）比操作本身还大，套 to_thread 只是
给同步调用加了层异步外壳，不产生任何并发收益；真正需要卸载的是整库复制、ZIP 整段
拷贝、SQLite 探测这类活。本批按这个口径把两端都摆正，并顺手修掉一处真实缺陷。

改动：
- web/routers/admin_site.py 备份上传：原 `content = await f.read()` 会把整库一次性
  读进内存（端点对外无大小上限，等于给了上传方一个内存放大器），落盘后还要把文件
  重新打开读一次头。改为 _save_upload_stream 按 1 MiB 逐块搬运——内存占用恒为一块，
  文件头在写第一块时就地截获（省掉那趟回读）。仍属阻塞 IO，故保留在 to_thread 里。
- web/routers/admin_site.py backup_list：撤掉仅为一次 stat 而拆出的嵌套函数 +
  to_thread，直接在事件循环里做完。
- web/routers/admin.py：save_cookie / logout / _get_cookie_info 四处 to_thread 改
  直接调用——它们读写 1KB 级的 cookie.txt，全程不碰网络。
- music_api/qr_client.py：logout() 的 print 改 logger。该方法既被 CLI 也被 admin
  端点调用，在 web 语境里 print 会把内容直接喷到服务端 stdout，绕过 logging 配置、
  无法被收集，也污染容器日志。
- auth_system/backup.py：三处单文件 unlink（占位文件回滚、删备份、裁剪 pre_restore_）
  改直接同步；把只为配合 to_thread 而拆出的 _backup_path_sync 并回 backup_path。
  保留在线程里的：整库 copy2 / os.replace、glob + N 次 stat、SQLite 探测、以及持
  跨线程锁的 _reserve_backup_path（内联会让事件循环等一把别的线程可能持有的锁）。
- web/routers/delivery.py：两处 os.path.exists 改直接同步（带 ASYNC240 行内豁免，
  与 core/db.py、auth_system/db.py 同一写法），顺带删掉随之未使用的 asyncio 导入。
- pyproject.toml / uv.lock：移除 aiofiles。它全仓零引用，且底层同样是 to_thread——
  对 1KB 的 cookie 文件不会带来任何真异步收益。

验证：
- uv run ruff check .  → All checks passed!
- uv run pyright       → 0 errors, 0 warnings, 0 informations
- uv run pytest        → 392 项，0 失败 / 0 error / 0 skipped
  （含 test_admin_backup_upload 四条：接受真实 SQLite / 缺字段拒 / 后缀拒 /
   后缀对但内容非库必须拒且不留半成品）
- data/site.db sha256 前后一致（a19f5dbf…6487），无 -wal/-shm 残留

pyproject.toml

@@ -9,7 +9,6 @@ dependencies = [
     "uvicorn[standard]>=0.30,<1.0",
     "aiohttp>=3.10,<4.0",
     "aiosqlite>=0.20,<1.0",
-    "aiofiles>=24.1",
     "itsdangerous>=2.2,<3.0",
     "cryptography>=50.0,<51.0",
     "qrcode>=7.0,<8.3",