fix(download): M295 r2 —— 代理地址四类原因各一句中文，不再摊 reqwest / url 的原文

r2 复审退回的形态：`代理地址无法解析（http://127.0.0.1:99999）：builder error`。第一版靠
`Proxy::all` 的报错（只有这一句），第二版靠 `url::ParseError` 的 Display（英文 `invalid port
number`，而且 reqwest 的宽口径会让「解析成功/失败」本身不可靠）——两种都还是把别人的原文当结论。

- `validate()` 自己判四类，各给一句中文：scheme 不支持 / 缺少主机名 / 端口（空、0、越界）/ 空地址；
  `manual_proxy` 先过它，再 `Proxy::all`。
- 残余情形（validate 放行但 reqwest 不认，例如 userinfo 有非法字符）：中文结论在前，reqwest 原文
  只作为括号里的证据。
- 判据改成「文案里命中该类中文原因，且不含 `builder error` / `invalid port number`」，四类表驱动
  + 合法写法（含 `[::1]:8080` 与少写 scheme）不许被拒。
- 实测（真二进制，`ull install 1.20.1 --dry-run`，口令样本 PWMUSTNOTLEAK）：
  `代理地址用不了（http://user:***@127.0.0.1:99999）：端口 99999 不是 1–65535 之间的数字`
  `代理地址用不了（socks5://user:***@127.0.0.1:1080）：本构建不支持 socks5 代理（只支持 http / https）`
  口令出现 0 次。
- 变异（本轮重做）：关掉端口判定 ⇒ 红，且红的样子正是「地址写法不被接受（builder error：invalid
  port number）」——证明没有自己的判定时原文就会漏出来；关掉主机名判定 ⇒ 红；scheme 白名单写
  `if false` ⇒ 红；`redact_proxy_url` 返回原文 ⇒ 3 条红（口令泄漏）。见 docs §6 M23/M25/M26/M27。
- 门禁（含塔点名的整棵 `-p unlucky-core --lib`）：914 passed / 0 failed；四 crate 测试 45 个
  binary、3206 passed / 0 failed；clippy `-D warnings`、`fmt --all --check`、
  `check --workspace --all-targets` 全 0。

crates/core/tests/download/engine_mock/proxy.rs

@@ -253,7 +253,9 @@ async fn an_unparseable_proxy_url_falls_back_to_direct_and_says_why() {
         .proxy_problem()
         .expect("地址解析不了必须留下原因（宿主靠它告诉用户）");
     assert!(problem.contains("http://127.0.0.1:99999"), "{problem}");
-    assert!(problem.contains("代理地址无法解析"), "{problem}");
+    assert!(problem.contains("代理地址用不了"), "{problem}");
+    assert!(problem.contains("端口 99999"), "原因要能读：{problem}");
+    assert!(!problem.contains("builder error"), "{problem}");
     assert_eq!(
         harness.engine.config().proxy,
         broken,