refactor: 两个「数据泥团」收成 dataclass / 字典

为什么：上一轮报告「11 个参数 > 6」的清单实测只有 7 个 ≥7 参数，其中真正
该改的是 2 个（另 5 个是 HTTP/下载原语的参数透传，合并反而降低清晰度，有意
保留）。

1) auth_system.create_user（11 参 → 6 参）
   前 5 个是账号属性（username/password/email/credits/role，同属一个概念），
   后 6 个才是泥团——它们是「注册风控上下文」（同 IP 频率闸 + 设备赠送闸）。
   收成 frozen dataclass RegistrationGuard，默认值等价于「不做任何风控」，故
   老调用点语义不变。

2) web/routers/download.py._single_task（11 参 → 2 参）
   11 个位置参数改成一个 params 字典 + device_id，字典原样透传给 worker。
   顺带删掉原本就**未被使用**的 data 参数（11 个里有 1 个是死的）。
   理由不是「参数多」而是这 11 个位置参数没有名字，调用点极易错序。

教训：create_user 签名重构时漏改 web/routers/admin_site.py:155，pytest 189 例
全绿（该端点无测试覆盖）但 pyright 报出 2 errors —— 两道门禁互补的实证，
说明类型检查不是冗余。

web/routers/admin_site.py

@@ -151,8 +151,9 @@ async def user_create(admin: AdminUser, request: Request):
             return error('用户名已存在')
         if email and await asyncio.to_thread(auth.get_user_by_email, email):
             return error('该邮箱已被注册，请更换邮箱')
-        await asyncio.to_thread(auth.create_user, username, password, email=email,
-                                credits=credits, ip='-', ua='admin创建')
+        await asyncio.to_thread(
+            auth.create_user, username, password, email=email, credits=credits,
+            guard=auth.RegistrationGuard(ip='-', ua='admin创建'))
         await _log(admin, '添加用户', f'{username} · {credits} 次')
         return success(message=f'用户 {username} 创建成功（{credits} 次）')
     except Exception as e: