security: validate key query param against redis key injection + document API_KEY

[Germey]

背景

Issue 收敛计划 Phase 3（安全加固），对应 #228。

问题（来自 #228）

1. API_KEY 默认空串 → 部署到公网后 /random、/all、/count 全部无鉴权可访问。
2. /random?key=xxx 把 key 直接当作 Redis key 名传入，可用于探测其他 zset。
3. README 未提及 API_KEY。

改动

• key 参数校验（server.py）：新增 get_request_key()，用白名单字符集 ^[a-zA-Z0-9_:\-]{1,64}$ 校验 key，非法输入直接返回 400。/random、/all、/count 统一走该校验，杜绝任意 Redis key 探测/注入。空 key（?key=）保持原「回退到通用池」行为。
• 顺手修一个历史小 bug：/count 在不带 key 时直接 return conn.count()（int），而 Flask 视图不允许返回 int（会 500）。改为始终返回字符串。
• 文档（README.md）：补充 API_KEY 配置说明，并新增醒目的「安全提示」——暴露公网务必设置 API_KEY 并配合防火墙/安全组。

关于「默认鉴权」的取舍

#228 建议 #1 是「默认生成随机 API_KEY」。考虑到 README 的快速上手（docker-compose up 后直接 curl /random）完全依赖免鉴权，默认强制鉴权会破坏开箱即用体验，因此本 PR 采取「默认开放 + 文档强提示 + 参数校验」的稳妥方案。如果你倾向默认强制鉴权，我可以再补一版（自动生成并在启动日志打印 key）。

验证

• server.py 编译通过。
• 正则用例：proxies:weibo / proxies:universal / abc_123 / 空串 → 放行；含空格 / * / ../etc / 换行 → 400。

关联 issue

• Refs [Security] Default empty API_KEY + Redis key injection via query parameter #228（key 注入 + 文档已解决；默认鉴权按上文取舍留待你决定）