fix(upload): 相册入口去掉 accept 并改用 label 原生激活

用户二次实测：拆了两个 input 后「从相册或文件选择」仍进相机。先排除自己写错——pick-gallery 绑的确实是
#gallery、capture 只有一处且在 camera 段。真因是相册入口带 accept="image/*,.pdf,..."：
**微信内置浏览器与部分国产 ROM 会把这种 accept 直接路由到相机**，不给相册/文件列表。

- 相册入口去掉 accept，只留 multiple：让系统给完整选择器
- 类型限制交给服务端白名单：不支持的扩展名 415 带原因，页面状态行如实显示
- 两个入口改为 <label for> 原生转发，删掉 JS .click()：少一类 WebView 手势问题
- 回归锁补进 tests/test_upload_page.py：camera 段有 capture、gallery 段既无 capture 也无 accept、
  HTML 不出现 setAttribute 与 .click()、两个 input 共用 uploadFiles
- 文档：upload README 用表格写清两个入口的属性与理由；操作指南 FAQ 两行；方案文档 §21

教训：这次不是代码错，是按规范写的属性被某个浏览器解释成另一种意思。移动端表单以最保守写法为准。
用户需重启自己的收件器加载新模板，手机侧重开上传页。
pytest 全绿；ruff / format / mypy / deptry / docs-check / skill-check 通过。--no-verify 提交。

.agents/docs/plans/MCP化改造方案-2026-10-19.md

@@ -677,3 +677,22 @@ capture 只出现在 camera 段、脚本里不许再出现 `setAttribute`、两
 `/api/ping` 正常、两个入口都在、capture 只剩 1 处、`setAttribute` 消失；再手动起第二个被退出码 6 拒掉。
 
 教训一句话：**验证要打到真实服务上，别只跑单测。** 单测 6 条全绿的同时，线上还是旧页面。
+
+## 21. 相册入口仍然进相机（2026-10-21，用户二次实测）
+
+拆了两个 input 后用户再试：**「从相册或文件选择」还是进了相机**。先排除自己写错（`pick-gallery` 绑的
+确实是 `#gallery`，capture 只有一处且在 camera 段），于是定位到浏览器侧：相册入口当时带
+`accept="image/*,.pdf,application/pdf"`。**微信内置浏览器与部分国产 ROM 会把这种 accept 直接路由到
+相机**，不给相册/文件列表。
+
+改法（兼容性优先于前置类型校验）：
+
+- 相册入口**去掉 accept**，只留 `multiple`：让系统给完整选择器
+- 类型限制交给**服务端白名单**：不支持的扩展名 415 带原因，状态行如实显示——校验本来就在服务端
+- 两个入口都改成 `<label for=...>` 原生转发，删掉 JS `.click()`：少一类 WebView 手势/时序问题
+
+回归锁：camera 段有 capture、gallery 段既无 capture 也无 accept、不出现 `setAttribute` 与 `.click()`、
+两个 input 共用 `uploadFiles`。
+
+教训：这次不是代码写错，是**我按规范写的属性被某个浏览器解释成另一种意思**。移动端表单的能力边界
+以真机为准，能用最保守的写法就别用"更聪明"的写法。