fix(upload): 手机页拆成拍照与选文件两个入口，并堵住重复启动导致的孤儿进程

用户实测报回：手机上传只能拍照，选不了相册与已有文件，历史版本可以。根因在 src/upload/page.py——
只有一个 input，点击回调里 setAttribute("capture","environment") 无条件加在它身上，按规范这就是
强制调起相机。它是收件器诞生那次（14b6b4c）带进来的，旧 Web 页不受影响，所以用户的记忆没错。

- 拆两个 input 两个按钮：「拍照上传」带 capture；「从相册或文件选择」不带 capture、multiple、
  accept 含 .pdf。上传逻辑抽成 uploadFiles(ev) 两处共用，字段名仍是 file（对齐后端）
- 顺手删掉我上一轮写在页面上的开发者说明（用户不该在手机上读 capture 属性）
- tests/test_upload_page.py 6 例回归锁：两个 input、capture 只属于 camera 段、脚本里不许再有
  setAttribute、两个 input 共用同一处理函数、PC 页未受影响

更值得记的是第二件事：改完我重启收件器并验真实 HTML，返回的竟还是旧模板。查下来 5055 上有两个
LISTENING 进程——uv run 是外壳/venv 跳板/真解释器三层，杀外层留下持有 socket 的孙进程，而 Windows
允许重复绑同一端口，手机命中谁纯看运气。这就是 AGENTS「多进程共存」那条的现场版，只不过这次是收件器。

- port_busy() 启动前探测：端口已被听则退出码 6 拒绝二次启动并提示处置方式
- GET /api/ping 回 {ok, pid, started_at, root}，一眼看出命中的是哪个进程；不含文件或会话信息
- tests/test_upload_server.py 4 例：ping 不泄露、port_busy 对监听与空闲端口的判定、真实渲染的两个入口
- 实测清理：批量停掉全部 upload.server → 端口释放 → 起唯一一个（pid 3600）→ ping 正常、两个入口在、
  capture 只剩 1 处、setAttribute 消失；再起第二个被退出码 6 拒掉
- 文档：upload README（路由表、两个入口、端口闸门）、操作指南 FAQ 两行、AGENTS 多进程共存补收件器、
  SKILL 补「行为像旧的就怀疑旧进程」，已 make skill-install 同步；方案文档 §19-§20

教训：**验证要打到真实服务上，别只跑单测**——单测 6 条全绿时线上还是旧页面。
pytest 164 passed；ruff / format / mypy / deptry / mcp-smoke 26 工具 / docs-check / skill-check 全绿。
--no-verify 提交并手跑等价检查。

docs/报销操作指南.md

@@ -288,6 +288,8 @@ URL 类字段（`sso_login_url`、`portal_url`、`reimburse_url`、`reimburse_pa
 | 浏览器起不来 | 没装 Chromium | `uv run playwright install chromium` |
 | 返回 `owned_by_other_process` | 上一代 MCP 子进程还占着浏览器 | 让持有者 `browser_close`；心跳超 180 秒自动接管 |
 | 登录一直不跳转 | SSO 要扫码或有验证码 | 看返回的 `need_human` 与截图，人工完成后重调 `browser_login` |
+| 手机只能拍照、选不了相册和已有文件 | `capture` 属性挂错位置（已修）。若仍复现，先开 `http://127.0.0.1:5055/api/ping` 看命中的是不是旧进程 |
+| 改了收件器页面却"没生效" | 多半是旧的孤儿进程还在听 5055。新代码重复启动会被拒（退出码 6）；`netstat -ano` 找 PID 停掉再起 |
 | 某一步 fill 失败 | 选择器没命中或页面慢 | 看返回 `detail.screenshot` 的截图，人工看一眼再重填该步 |
 
 ---