perf(harness): verify-ui-states.sh 每个 feature 起一次 Next dev server —— 复用一个实例（#1010 修法③）

## 背景

来自 #1010 的定论：`harness verify` 里 `verify:base` 之所以被压垮，是因为它前面的 feature 验证各起了一次完整 Next dev server。

`apps/web/scripts/verify-ui-states.sh:17`：

```bash
npx next dev -p "$PORT" >/tmp/ui-gate.log 2>&1 &
```

该脚本是 **F34** 与 **F50** 两个 feature 的 verification 命令 ⇒ 一次 `harness verify` 会**起两次**完整 dev server，且 load average 是衰减均值，kill 后仍高位停留数分钟，紧接着跑的 `verify:base` 因此挨打。

## 现状与优先级

#1017（spawn 超时重试一次）已从**另一侧**解决了门被压垮的问题——所以本 issue **不阻塞任何人**，属于纯优化：少起一个 dev server 能让整条 verify 更快、峰值负载更低（实测峰值 70 进程 / load 27，10 核机器）。

## 修法方向

让多个 feature 的 UI 状态断言**复用同一个 dev 实例**，而不是每个 feature 起一次。可能的做法（未深究，留给 harness 线定）：

- 脚本支持传入已就绪的 `PORT`，由 verify 编排层起一次、跑完统一收；或
- 脚本内做「端口已就绪则复用、否则自己起」的探测（注意 cleanup 只能收自己起的那个，别 kill 别人的）。

⚠️ 注意保住现有的 `cleanup()` 语义（`verify-ui-states.sh:13`）——复用后**不能**把别人起的实例 kill 掉。

## 不要顺手做的事

不要为了降负载去调 `.harness/scripts/fullstack-smoke.test.ts` 的超时常数——#1010 与 #1017 已经把那条路走完了（重试一次，而非放大常数）。

---

发现来源：dev-project 收口 F158 时的负载分析，见 #1010。

/cc @coord-main

Start with apps/web/scripts/verify-ui-states.sh, especially cleanup() at line 13 and the Next dev-server launch at line 17, then trace how F34 and F50 are invoked by harness verify. Choose an orchestration or port-reuse approach that preserves ownership-aware cleanup; done means both feature checks reuse one ready server without killing an externally started instance, and verify:base sees lower peak load.

Written by the indexing model from the issue text.