fix(download): 多网卡按 IP 选 PG/PC 接口 + 可显式指定/可诊断 (#14)

[bulaofen0036-coder]

Fixes #14.

根因

DownloadToPlc 旧逻辑取第一个能 ApplyConfiguration 的 ConfigurationTargetInterface。但 ApplyConfiguration 只返回「这条在线路由是否配置成功」，它不校验可达性 —— 对 WLAN / VPN 虚拟网卡同样返回 true。于是在多网卡机器上（WLAN + VPN + PLCSIM 虚拟网卡），下载从一块根本看不见 CPU 的网卡走出去，报「连接到模块失败 / Connection to the target module cannot be established」，而 CheckDownloadReadiness 还返回 ready: true。

改动

Portal.Download.cs：TrySelectDownloadTargetInterface → SelectDownloadRoute。

1. 按 IP 自动选路。全量枚举 Modes → PcInterfaces → TargetInterfaces 成候选路由并打分：PG/PC 网卡自身 IP 与目标 CPU IP 同一 IPv4 /24 者优先。
2. 可显式指定。DownloadToPlc 新增可选入参 pgPcInterface（网卡名子串，不区分大小写）与 targetIpAddress（目标 CPU IP）。填了却匹配不到时报错并列出全部可用路由，不静默回落。
3. 可诊断。CheckDownloadReadiness 的 meta.downloadRoutes 只读列出每条「PG/PC 网卡 → CPU 接口」路由及两端 IP（preferred=true 表示同网段）；DownloadToPlc 成功时 meta.pgPcRoute 回报实际走的网卡，失败时错误信息附「已用路由 + 全部候选 + 覆盖参数用法」。

兼容性

同分时保持原枚举顺序 —— 所有候选都不占优（PROFIBUS/MPI、或确实没有网卡在 CPU 网段）时，行为与旧的 first-wins 完全一致。新入参全部可选，现有调用不受影响。

已知假设

Openness 的 ConfigurationAddress 只暴露地址、不暴露掩码，所以 /24 是假设。它只用于给候选排序，绝不用于否决下载 —— 猜错最坏情况是退回旧行为，不会把本来能下的下载挡掉。

验证

• 新增 scripts/Test-DownloadRouteSelection.ps1：离线、不需要连 TIA，用伪造的多网卡对象图跑真实选路代码（EnumerateDownloadRoutes / ScoreDownloadRoutes / SelectDownloadRoute 全是反射，POCO 即可驱动）。覆盖：自动选中 PLCSIM / 显式 IP / 显式网卡名覆盖排序 / 两种匹配失败的报错含路由清单 / 同分回落原顺序，外加一条必错哨兵（哨兵若通过说明测试本身坏了）。7/7 过。
• V21 编译 0 错。

未做

• V20 未编译（构建机无 TIA V20）。改动无版本相关 API，风险低，发版前需在有 V20 的环境回归。
• 真机 / PLCSIM 未端到端复现（没有 issue 里那套三网卡环境）。排序逻辑是离线验证的，已在 issue 下请报告人回验 meta.downloadRoutes。
• CHANGELOG 条目写为 [未发布]：版本号待与另一条未合并的公开线分支统一后再定。