test(net): 去掉 net 测试的 flaky，顺带把整套 ctest 从 78.7s 降到 8.7s

全量 ctest 连续两次各挂一个 net 测试，且挂的不是同一个，压测后定位到
四个互相独立的原因，全部在测试自身，产品代码未改动。

1. accept_loopback(): poll() 的 `<= 0` 把 EINTR 当成对端从未连接，且单片
   500ms 超时在有负载时不够。50 轮压测里 4 次失败全部源于此。改为 EINTR
   重试 + 5s 截止时间（listener 本就非阻塞，超时后 accept 不会挂住）。
2. :570 的 pump 循环条件抄自上面的死端口用例，但此处 connect 会成功，
   stage 先经过 LoggingIn，循环提前一步退出。
3. 同文件 5 处手写 pump 循环只给 10-20ms 等真实 loopback socket。新增
   pump_until(session, want, max_ms=2000) 统一替换，等的是断言真正关心
   的那个状态。
4. net_loopback_test 的 10 处 run(..., N, []{return false;}) 是固定空转
   而非等待条件。服务端批量收包改用该批最后一个包的标志作条件（TCP 有序），
   客户端事件用本地累加器在谓词里 drain。

提速：两处 this-*-host-must-not-resolve.invalid 换成带空标签的名字。本机
解析器不按 RFC 6761 本地拒绝 .invalid，每次发往上游等满 30s 超时；空标签
让 getaddrinfo 在语法层返回同一个 EAI_NONAME，实测 <10ms。
net_classic_session_test 61.2s -> 3.5s；loopback 改条件退出后 0.94s。

验证：net_classic_session_test 100/100（修复前 50 轮挂 4 轮）；
net_loopback_test 100/100（修复前单独跑第 7 轮即挂）；全量 ctest 27/27；
port_map.py check 0 error；8 个 pack key 值均未入库。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

audit/history.jsonl

@@ -498,3 +498,4 @@
 {"time": "2026-09-23T21:40:00Z", "event": "port_round", "unit": "PORT-PLAN 批次 2P step 3c: staging python27.zip into the mobile sandbox", "ported": [], "adapted": [], "deleted": [], "divergent": [], "needs_live": [], "staging": {"ships": "make_stdlib_zip.py also writes <out>.sha256; target mtpython_stdlib_project copy_if_different's python27.zip + .sha256 into project/ (gitignored), and both export presets' include_filter lists them so they enter the PCK", "runtime": "extension/src/python_stdlib.cpp (GDScript: Metin2Python.stdlib_path(force_stage)) — desktop uses ProjectSettings.globalize_path(res://python27.zip) in place; exported builds read the bytes out of the PCK, write user://python27.zip.part, verify the sha256 of the written file, then rename to user://python27.zip. An existing sandbox copy is reused only when it hashes to the shipped digest, so a torn first start or a new build re-stages.", "handoff": "PythonHost::SetDefaultStdLibPath() — DefaultStdLibPath() now answers with the staged path; $MT_PYTHON_STDLIB still wins. python_stdlib.cpp is the only unit that knows res:// / user://; port_platform stays godot-free.", "build_fix": "the Windows gate (MinGW, no mtpython) was broken by step 3b and is fixed here: port/CMakeLists.txt now also excludes UserInterface/StdAfx.h (it includes ScriptLib/StdAfx.h, as the original PCH does) and UserInterface/PythonPackModule.cpp, and platform/CMakeLists.txt excludes platform/ScriptLib/ the way port_logic already excluded port/ScriptLib/."}, "status_note": "On-device staging is not verified: the macOS test drives the mobile path with force_stage=true, and Android/iOS user:// sandboxes come with step 4. The zip's presence in an exported pack was checked with --export-pack, not with an APK. Nothing in the app's boot path calls Metin2Python.stdlib_path() yet — the interpreter only starts in the process with 2V0; today the test is its only caller.", "tests": ["project/python_stdlib_test.gd (godot --headless --path project --script python_stdlib_test.gd) -> PASS: in-place path on desktop; force_stage copies into user://, sha256 matches the shipped digest, bytes equal res://, no .part left, ZIPReader opens it and finds encodings/__init__.py and os.py; a second call does not re-copy (mtime unchanged); a deliberately corrupted sandbox copy is re-staged", "godot --headless --export-pack macOS <zip> lists python27.zip (6876547) and python27.zip.sha256 (65)"], "not_done": "真机验证（Android/iOS 进程内落盘 + system.py -> prototype.RunApp()）随 2P step 4；Linux/Windows 见 step 4 表格", "commit": "2P-step3c"}
 {"time": "2026-09-23T22:20:00Z", "event": "scope_decision", "unit": "目标平台收窄为 macOS arm64 + Android arm64（Linux / Windows 不做）", "ported": [], "adapted": [], "deleted": [], "divergent": [], "needs_live": [], "decision": {"by": "user", "statement": "Linux 和 Windows 不考虑，目前主要支持 macOS arm64 和 Android arm64", "ios": "iOS arm64 保留为交叉编译干净的次要目标，不作为验收目标（我的判断，待用户确认）", "mingw": "仓库里的 mingw-w64 交叉编译只留作可移植性门禁——它这次抓到了 UserInterface/StdAfx.h 的真问题——不代表支持 Windows，不为它投入额外工作，也不阻塞任何步骤"}, "docs": ["docs/PORT-PLAN.md: 第 1 节新增范围段；批次 2A step 3 平台列表；批次 2P step 1/2 措辞；step 4 由「五个平台」改为「两个目标平台」，Linux/Windows 两行划掉并保留原因备查；总表 2P 行", "docs/PLATFORMS.md: 新增 Scope 段", "docs/THIRD-PARTY.md: CPython 的 Windows 段由「not built yet」改为 out of scope + 原因备查", "docs/PYTHON-EMBED-EVAL.md: 下一步 1/3 两条"], "tests": "仅文档改动，无代码改动；port_map.py check 0 error / 1 tag；参考 EterPack.cpp 的 8 个 pack key 值逐个 git grep --cached -w，均未入库", "not_done": "2P step 4 剩余项仍在：Android 真机 APK 进程内的 3c 沙盒落地，以及 app 进程里跑 system.py → prototype.RunApp()"}
 {"time": "2026-09-23T22:35:00Z", "event": "known_issue", "unit": "Android GBK 编解码挂起；优先保证 macOS 可用", "ported": [], "adapted": [], "deleted": [], "divergent": [], "needs_live": [], "decision": {"by": "user", "statement": "先不管这个问题了，先保证 macOS 能正常使用，Android 后期再想办法"}, "finding": {"symptom": "build-android.sh 默认 API 24 下 extension/src/net/text_codec.cpp 编译失败：use of undeclared identifier 'iconv_open' / 'iconv' / 'iconv_close'", "root_cause": "text_codec.cpp:10 用 __has_include(<iconv.h>) 探测。NDK 里该头在任何 API 等级都存在，但声明被 __BIONIC_AVAILABILITY_GUARD(28) 挡住，探测方式与 bionic 的可用性模型不匹配", "measured": "NDK 28.2.13676358 clang++ -fsyntax-only：--target=aarch64-linux-android24 报 3 处 undeclared；android28 通过", "why_api_bump_is_wrong": "NDK iconv.h 注释写明 bionic 只支持 utf8/ascii/usascii/utf16be/utf16le/utf32be/utf32le/wchart，没有 GB2312/GBK。升到 28 后 iconv_open(\"GB2312\",\"UTF-8\") 运行期返回 -1，encode_one()/decode_wire() 对所有输入都返回 false，连纯 ASCII 也被拒，比现有 #else 的 ASCII 回退分支（text_codec.cpp:104-127）更糟。附带成本：APK min_sdk 需 >=28；config/android/pyconfig.h 是 API 24 下 configure 的（HAVE_LANGINFO_H 因 nl_langinfo 需 API 26 被关掉），要重跑 gen_pyconfig.sh android 并重验内建模块表", "future_fix": "1) 探测改为 #if __has_include(<iconv.h>) && !defined(__ANDROID__)，不要写 __ANDROID_API__ >= 28；2) Android 自带 GBK<->Unicode 表（约 22k 码位）。40250 原客户端走 Windows MultiByteToWideChar(CP949/CP936)，跨平台无对应物；macOS 能用只是系统 libiconv 恰好带 GBK"}, "docs": ["docs/PORT-PLAN.md 新增「已知问题：Android 的 GBK 编解码（挂起，2026-09-23）」小节"], "tests": "仅文档改动；诊断由 NDK clang++ -fsyntax-only 双 API 等级实测得出", "not_done": "text_codec.cpp 未改动；Android 扩展构建目前仍是红的"}
+{"time": "2026-09-23T23:30:00Z", "event": "test_fix", "unit": "net 测试去 flaky：net_classic_session_test + net_loopback_test", "ported": [], "adapted": [], "deleted": [], "divergent": [], "needs_live": [], "trigger": "macOS 全量 ctest 连续两次各挂 1 个 net 测试，且每次挂的不是同一个（第一次 net.loopback_flow，第二次 net.classic_session）", "root_causes": ["accept_loopback(): poll() 的 `<= 0` 把 EINTR 当成对端从未连接；且单片 500ms 超时在有负载时不够。50 轮压测里 4 次失败全部源于此", "net_classic_session_test.cpp:570 的 pump 循环条件抄自上面的死端口用例，但此处 connect 会成功，stage 先经过 LoggingIn，循环提前一步退出", "同文件 5 处手写 pump 循环只给 10-20ms 等真实 loopback socket（非阻塞 connect 完成 / connect 被拒 / 对端 FIN）", "net_loopback_test.cpp 10 处 run(..., N, []{return false;}) 是固定空转而非等待条件，等不够就断言失败"], "fixes": ["accept_loopback() 改为 EINTR 重试 + 5s 截止时间（listener 本就是非阻塞，超时后 accept 不会挂住）", "新增 pump_until(session, want, max_ms=2000)，替换全部 5 处手写循环；等的是断言真正关心的那个状态", "替换 replacement PHASE_LOGIN 处的单次 pump（前一条 CHECK 已经断言过「不在同一帧」，这里只需要后续某次 pump 收到）", "net_loopback_test 的 10 处固定空转改为条件等待；服务端批量收包用该批最后一个包的标志作条件（TCP 有序，最后一个到了说明前面都到了），客户端事件用 decltype 声明的本地累加器在谓词里 drain"], "speedup": {"net_classic_session_test": "61.2s -> 3.5s：两处 this-*-host-must-not-resolve.invalid 换成带空标签的名字。本机解析器不按 RFC 6761 本地拒绝 .invalid，每次发往上游等满 30s 超时；空标签让 getaddrinfo 在语法层返回同一个 EAI_NONAME，实测 <10ms", "net_loopback_test": "固定空转改条件退出后单跑 0.94s", "ctest_total": "78.7s -> 8.7s"}, "tests": "net_classic_session_test 100/100（修复前 50 轮挂 4 轮）；net_loopback_test 100/100（修复前单独跑第 7 轮即挂）；全量 ctest 27/27；port_map.py check 0 error；参考 EterPack.cpp 的 8 个 pack key 值逐个 git grep --cached -w，均未入库", "not_done": "只改测试，未改产品代码。这些都是测试自身的计时/错误处理缺陷，不是 mtnet 的行为问题"}