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，
要按上述两件事继续排查。

deploy/proxy/README.md

@@ -236,7 +236,9 @@ firewalld / ufw / iptables 的放行情况，并直接给出修复命令。
 > **Gitea**（源码仓库 + Release 附件）的站点。Windows 客户端的发布整包走 Gitea，
 > 因此**必须**单独放开 Gitea 站点的上限。
 
-### 9.1 实测结论
+### 9.1 实测结论（两阶段）
+
+**第一阶段（IIS 上限未放开时）**
 
 | 上传体积 | 结果 |
 |--|--|
@@ -244,6 +246,34 @@ firewalld / ufw / iptables 的放行情况，并直接给出修复命令。
 | 30.5 MB | **失败 HTTP 413**（IIS「请求实体过大」页面） |
 | 40 MB | **失败 HTTP 413** |
 
+**第二阶段（IIS 上限放开之后）** —— 放开的效果是**可验证**的：
+38,245,661 字节的请求体被**完整接收**（耗时 115 s），不再出现 413，
+说明 IIS 的 `maxAllowedContentLength` 已经够用。但随后 **Gitea 自己返回 HTTP 500**
+（响应体是 Gitea 的 API 错误信封 `{"message":"","url":".../api/swagger"}`，
+`message` 为空）——即瓶颈已从 IIS 转移到 Gitea 侧。
+
+同阶段的边界测量（同一个 Release 的资产上传接口）：
+
+| 上传体积 | 结果 |
+|--|--|
+| 914 KB（web v0.7.1 tar.gz） | 通过 |
+| 16,372,427 B（android v0.2.0 zip） | 通过 |
+| 16,400,000 B | **HTTP 500** |
+| 16,500,000 B / 18 MB / 21 MB / 24 MB | **HTTP 500** |
+| 100,000 B（在第一轮失败之后） | **HTTP 500，且仅耗时 0.3 s** |
+
+最后一行是关键：**在若干次大包失败之后，连 100 KB 都会在 0.3 秒内 500** ——
+这不符合"上传体积上限"的特征（上限判断会先读完请求体），
+更像**上传临时目录 / 数据盘已满**（Gitea 先把请求体写入 `data/tmp`，
+失败时可能在磁盘上留下残留临时文件）。
+
+> **因此运维侧需要按顺序检查两件事**：
+> 1. **Gitea 数据盘的剩余空间**（尤其是 `data/tmp`，以及它是否落在小容量的
+>    tmpfs 上），并清理失败上传留下的临时文件；
+> 2. Gitea `app.ini` 的 `[attachment] MAX_SIZE`（下文第 3 条）。
+>
+> 只放开 IIS 是不够的：本节第 1 步之后仍然 500，说明还有 Gitea 侧的限制或磁盘问题。
+
 → 默认上限就是 **IIS 的 `maxAllowedContentLength = 30,000,000` 字节（≈28.6 MiB）**。
 Windows 客户端整包约 38 MB（`OpenDance.exe` ≈104 MB 未压缩 + `OpenDance.pck`），
 早先因此被拆成 `zip.part0/1/2`（每卷 13 MiB）才传上去 —— 用户拿到的是
@@ -302,6 +332,10 @@ Windows 客户端整包约 38 MB（`OpenDance.exe` ≈104 MB 未压缩 + `OpenDa
 
 5. 改完执行 `iisreset /noforce`（或只重启站点），再按下节复验。
 
+> **注意**：`requestLimits` 只是第一道闸。IIS 放开后若仍为 500（而不是 413），
+> 说明请求体已经到达 Gitea，此时要按 9.1 的两件事继续排查
+> （Gitea 数据盘空间 / `[attachment] MAX_SIZE`）。
+
 ### 9.3 复验方法
 
 ```bash