fix(test-isolation): 端口按 run id 哈希分配，撞上孤儿进程占用的端口段直接判失败（本轮取证 1/6 次运行报废）

## 现象（本轮 UIUX 取证时真实撞到，1/6 次运行报废）

`with-test-isolation.ts` 分配到的端口段与机器上**遗留的孤儿 dev server** 撞车，
整次运行 0 秒失败，产出一个和被测代码毫无关系的红：

```
[stack-admission] load1=4.23 cores=10 perCore=0.42 running=1/2
[test-isolation] id=run-mtc377gc-d580fdae-53dca6a7c966 db=wsx_53dca6a7c96660bab65f compose=wsx-53dca6a7c96660bab65f pg=24511 redis=29511
Error: http://127.0.0.1:59511/healthz is already used, make sure that nothing is running on
the port/url or set reuseExistingServer:true in config.webServer.
```

`lsof` 实测确认 59511 被另一个会话遗留的 node 进程（pid 8297）占着，
同一批还有 `55511 / 50511 / 51511 / 40511`——即整个 `*511` 端口段都被一个早已结束的
会话的孤儿进程霸占。租约目录 `.harness/state/.cache/stacks/` 当时是**空的**，
所以准入检查放行了，端口探测才在起服务时才发现。

## 为什么值得单开

- 它长得**完全不像**基础设施问题：报错在 `webServer` 阶段，日志里只有一行 URL 被占用，
很容易被当成「本机脏了，重跑一下」而不留痕；本轮如果不是恰好在做 A/B 对照、
对每一次运行都要归因，这一次就会被静默重跑掉。
- 它会把一次本该绿的运行变红，正是 #2258 那类「共享机器抖动 vs 真实回归」争议的**制造者之一**。
- 端口是**按 run id 哈希**推出来的，不是「探测一个空闲端口再用」，所以撞车不是小概率——
只要孤儿进程还在，撞到同一段的后续 run 会反复失败。

与既有 issue 的关系：#583（准入分母是 CPU 核）与 #1722（准入数的是租约不是真实栈）说的是
**并发度**；本条说的是**端口分配策略**——即使并发度是 1 也照撞，是另一个根因。

## 建议修法（供实现者取舍，不替人定）

1. 起服务前先探测端口段是否真空闲，撞了就换一段重试（而不是直接失败）；
2. 或者把端口从「run id 哈希」改成「向 OS 要一个空闲端口」；
3. 附带：准入前扫一遍 `lsof` 上带 `wsx-`/worktree 路径特征的孤儿 node 进程并告警，
让人看得见「这台机器上有我不知道的东西在占资源」。

## 复现

机器上存在任一监听 `*511` 段的孤儿 next dev 时，跑任意
`pnpm exec tsx .harness/scripts/with-test-isolation.ts -- ...`，
只要 run id 哈希落到该段即复现。

Read .harness/scripts/with-test-isolation.ts and reproduce with pnpm exec tsx .harness/scripts/with-test-isolation.ts -- ... while an orphan next dev process occupies a hashed port segment. Trace how the run ID selects ports and how webServer startup reports collisions. Done means occupied segments are handled according to an explicit allocation strategy and the run no longer fails opaquely because of an orphan process.

Written by the indexing model from the issue text.