引入完整的服务端验证流水线、PoW 机制与行为特征评分

[techccy]

本次修改重构了 playcaptcha 的验证核心。在此之前，验证逻辑仅存在于客户端（ClawCaptcha.tsx）的内存判断，缺乏后端信任凭证。

本 PR 引入了一套完整的无状态签名 Token 流水线。在保留游戏化验证趣味性的同时，增加了防伪造、防自动化脚本攻击的能力，并完美兼顾了向后兼容性。

Architecture & Workflow

重构后的整体时序与数据流如下：

浏览器 (ClawCaptcha)                     服务器 (playcaptcha/server)
  │ GET 获取挑战 ────────────────────────►│ issueChallenge() — 生成 HMAC 签名
  │◄─ { 目标, PoW 种子, 过期时间, 签名 }    │
  │ 在后台解决 PoW (Web Crypto)           │
  │ 游玩：收集行为信号                     │
  │   · 摇杆轨迹（抖动、反转分析）          │
  │   · 计时（首次操作、总耗时）            │
  │   · 事件真实性 (event.isTrusted)      │
  │   · 环境嗅探 (navigator.webdriver)    │
  │ POST 发起验证 ───────────────────────►│ verifyAttempt()
  │◄─ { ok, token, score }              │   · 校验 HMAC 签名与过期时间
  │                                     │   · 校验 PoW 正确性
  │ onVerify(result)                    │   · 启发式行为评分
  │ 后续在业务后端调用 verifyToken()       │

Key Changes

1. 新增服务端与验证核心模块 (src/verify/, src/server/)

• verify/types.ts：提取并共享环境无关的接口与数据结构定义。
• verify/pow.ts：基于 crypto.subtle 实现客户端 PoW（工作量证明）求解器。采用异步让出 UI 线程的设计，确保在求解（默认约 14 位算力，耗时 < 1s）时 rAF 动画依然丝滑不卡顿。
• verify/signals.ts：实现 SignalCollector 挂钩至现有的操纵杆/键盘事件，并提供纯函数的 scoreSignals() 启发式评分逻辑。
• server/index.ts：提供 createVerifier() 核心入口。使用 Node.js 原生 crypto 进行无状态的 HMAC 签名校验、过期检查与算力复核，无需依赖任何数据库。
• **server/store.ts & handlers.ts**：提供可选的内存重放保护（ReplayStore）以及多平台兼容（兼容 Cloudflare Workers / Hono / Next.js / Bun 等）的 Fetch Handler 参考实现。

2. 客户端组件与构建配置调整

• ClawCaptcha.tsx：在组件挂载时自动预获取挑战并启动后台 PoW。接入信号收集器，并在游戏成功阶段通过异步请求进行服务器往返验证。新增了 verifying 状态及对应的“正在准备挑战...”、“正在与服务器验证...”等视觉提示。
• 打包与配置升级：调整 tsup.config.ts 和 package.json 实现多入口打包（新增 ./server 导出）。服务端代码与客户端 bundle 物理隔离，确保客户端代码不会错误导入 node:crypto。
• 文档更新：更新 README.md，新增“服务器验证”专栏，详述接入方法与安全边界。

Backward Compatibility

• 完全向后兼容：onVerify 的签名扩展为 (result?) => void。如果不开启服务端模式属性，现有的 <ClawCaptcha onVerify={() => unlock()} /> 将维持原有的纯客户端回调逻辑，现有用户的接入不会被破坏。

Testing & Verification

引入了完整的测试套件，目前 9/9 项端到端测试全部通过。测试场景复盖了：

1. 正常路径下的 Token 生成与二次验证
2. 合成伪造事件（isTrusted = false）拒绝
3. WebDriver 自动化工具特征拒绝
4. 签名篡改与过期令牌拒绝
5. 无效 PoW 算力拒绝
6. 接口防重放保护
7. 跨平台的 Fetch Handler 正常协同

Security Model & Limitations

本设计遵循了 reCAPTCHA / hCaptcha 的主流纵深防御哲学。由于验证码前端上报的信号和 PoW 结果属于客户端报告，服务器无法绝对“证明”物理抓取动作的发生。
因此，本架构的真实防线建立在：

1. 没有服务器私钥绝无法伪造的 HMAC 令牌；
2. 强制要求自动化脚本付出不可忽略的 CPU 算力成本（PoW）；
3. 捕获绝大多数常规机器人的多维行为启发式评分。
   相关限制已在 README.md 中坦诚说明，不向开发者夸大防御边界。