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 提交并手跑等价检查。

.agents/skills/reimbursement/SKILL.md

@@ -38,7 +38,7 @@ description: >
 2. 材料入库：`case_add_files(paths=[...])`——**绝对路径、正斜杠**（`C:/Users/xx/Downloads/发票1.pdf`）；
    材料可以来自任何目录（下载目录、微信文件目录、当前工程的临时文件夹），工具会拷进会话目录，
    原文件不动。手机上传先落 `inbox/`，再 `case_add_files(case_id, source="inbox")` 收取。收件器是**独立进程**
-   （`make upload`），没启动时用户那条直链必然打不开；多网卡机器还要在服务器侧 `config.json` 配
+   （`make upload`），没启动时用户那条直链必然打不开；用户说"能打开但行为像旧的"，多半是旧进程还在听
    `upload_base_url`（**带端口**，默认 5055），否则探出来的地址手机连不上
 3. `case_render_pages`：`text_chars > 0` 就 `case_read_text` 读文本层（比读图准且省 token），
    否则读它给的 `pages/<stem>/p01.png`。**文本层与读图结论冲突时两条都不许采信**（见下面硬纪律）