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