fix(tun): verify TUN interface up before marking ready (win32)

[Sway-Chan]

问题（#324）

Windows 10 下 TUN 无法开启，sing-box 启动期退出（TUN 初始化未完成），正在自动重试 每 ~6s 无限循环、永不成功。

诊断报告实证：sing-box 进程存活且 mixed 代理正常（youtube/cloudflare 经节点建连成功），但全程无 inbound/tun[tun-in]: started——TUN 网卡（flowz-tun0 / wintun）从未创建。旧就绪门只探管理 API 端口（非 TUN 接口真存在），无法区分「真起来」与「进程活但 TUN 没起」，落入误导性无限重试。

改动

• A1 起核后正向验证 flowz-tun0 适配器出现（waitForAdapterPresent，每腿独立验证），缺失=本腿失败；probe 自身失败（PowerShell 缺 / 被杀软拦）fail-open 放行；grace 轮询注入 isSuperseded，被接管抛 CoreStartSupersededError、绝不 stopCore（守 [Bug] 新版本偶发性singbox进程重启新日志 #176 双 TUN 释放纪律）。
• A2 就绪窗内并行 sticky 观测适配器，重试预算耗尽且全程未见→ CoreStartTunPersistentError 终态诊断，停「正在自动重试」误导，给可操作提示（wintun / 杀软 / 冲突 VPN）。
• 仅 win32 + TUN，macOS/Linux 零改动。

验证

• gate：tsc / jest（新增 ~36 tests，分类矩阵变异全覆盖）/ eslint 0。
• 三轮独立复审零 Crit/High/Med/Low/Nit（[Bug] 新版本偶发性singbox进程重启新日志 #176 回归、fail-open、每腿验证、平台隔离逐条核实）。

⚠️ 待真机验证 + 根因分层

本 PR 修的是 FlowZ 侧设计缺口（就绪门不验 TUN 接口 + 持续性失败当瞬态无限重试），把「假连接 / 误导性死循环」变成「正确检测 + 可操作诊断」。

但 reporter 实际 TUN 起不来的主因在其机器（wintun.dll 被杀软隔离 / 残留 adapter / 冲突 VPN / 或 alpha 核回归），本 PR 不直接修复该主因——需 reporter 开诊断采集（debug）重导抓 wintun 错误行确认。故暂不 Closes #324，待真机确认失败模式改善 + 主因定位后再定 issue 去留。

Refs #324

[Sway-Chan]

本 PR 不关闭 #324。修复范围仅限 FlowZ 就绪判定缺口——TUN 未起来时旧逻辑落入误导性无限重试，改为正确检测 + 可操作诊断，并守 #176 双 TUN 释放竞态。

reporter 环境侧「TUN 起不来」的主因（wintun 加载失败 / 残留 flowz-tun0 适配器 / 冲突 VPN / 可能的 alpha 核回归）不在本 PR 修复范围。

关闭 #324 需先定位主因：请 reporter 在 设置 → 日志 → 诊断 开启诊断采集（logLevel 拉到 debug）复现后重导，抓 singbox.log 中 wintun / tun-in 错误行。内核已升级至 1.14.0-beta.1（#326）作候选缓解，待真机验证。