docs(proxy): 记录 Gitea 附件上传上限的两阶段实测（IIS 放开后仍是 500）
按文档 §5.7 硬性要求 4「若用 A 方案，先在发布文档里记录实测上限」，把这次
Windows v0.2.0 整包（38,245,661 字节）发布的实测结果写进 deploy/proxy/README.md
第九节，并修正第九节里「只改 IIS 就够」的隐含假设：
第一阶段（IIS 未放开）：14 MB 通过；30.5 / 40 MB 返回 HTTP 413。
第二阶段（IIS 已放开）：38,245,661 字节的请求体被**完整接收**（115 s），
不再有 413 —— 说明 maxAllowedContentLength 已经够用；但随后 **Gitea 自己返回
HTTP 500**（响应体是 Gitea 的 API 错误信封，message 为空），瓶颈转移到了 Gitea 侧。
同接口边界测量：914 KB 与 16,372,427 B 通过；16,400,000 B 及以上失败；
且**在若干次大包失败之后，连 100 KB 都会在 0.3 秒内 500** ——
这不符合「上传体积上限」的特征（体积判断会先读完请求体），
更像上传临时目录 / 数据盘写满（Gitea 先写 data/tmp）。
因此文档明确要求运维按顺序查两件事：①Gitea 数据盘剩余空间（含 data/tmp，
以及它是否在小容量 tmpfs 上）并清理失败上传的残留临时文件；
②app.ini 的 [attachment] MAX_SIZE。并在 IIS 配置小节加醒目提示：
若放开 requestLimits 后仍为 500 而非 413，说明请求体已到达 Gitea，
要按上述两件事继续排查。
zijunchiang
698d60bb65