docs(topology): correct x.x.x.87 role from spurious second client to server control-plane NIC

User clarified that x.x.x.87 (redacted as 192.168.1.3) is in fact a
second NIC on the server host (the same machine running AI AGENT)
that is *not* taken over by DPDK and is reserved for kernel ssh
traffic. Earlier docs incorrectly labelled it as a backup/secondary
client. This commit corrects every site where that misinterpretation
appeared.

Correct three-IP topology now consistently expressed as:
- server data plane    x.x.x.176 -> 192.168.1.1 (DPDK PMD,  F-Stack)
- server control plane x.x.x.87  -> 192.168.1.3 (kernel,    sshd egress)
- client (only one NIC) x.x.x.67 -> 192.168.1.2 (kernel or F-Stack)

AI AGENT (server-local) -> ssh -> server control NIC x.x.x.87 ->
client x.x.x.67 sshd; benchmark data path stays on
client -> server data NIC x.x.x.176 (DPDK), physically isolated from
the ssh control channel.

Files changed:

cvm-bench-methodology.svg  (5 sites)
- server box header: drop the misleading single-IP subtitle, replace
  with a dual-NIC line stating data plane / control plane mappings
- ssh control channel arrow label: append explicit
  '(server control NIC x.x.x.87 -> client x.x.x.67)' annotation
- topology footer note: rewrite to say data NIC (.176) is DPDK-managed
  while control NIC (.87) stays in kernel for ssh
- swimlane SERVER header: 'SERVER  data x.x.x.176 / ctrl x.x.x.87'
- bottom footer: rewrite the D-segment legend to attribute each octet
  to its correct role (data / control / client) and the corresponding
  redacted form

cvm-bench-methodology.md (1 table + 1 paragraph rewritten)
- topology table replaces the bogus 'backup client' row with a proper
  'server control plane' row
- old duplicated 'control vs data plane separation' paragraph trimmed
  in favour of a single concise note that ssh traffic is physically
  isolated on a different NIC from the benchmark data path

runtime-fix-execution-log.md (3 sites)
- L210, L485, L602 previously wrote 192.168.1.3 (client) as the
  benchmarking peer; they are corrected to 192.168.1.2 (client) and
  augmented with the role of 192.168.1.3 (server control plane / AI
  AGENT ssh egress) so the three-way IP mapping is unambiguous in the
  long-term execution record

Verification:
- grep '备用' across all three files          -> 0 hits
- grep '9\.134' / '\b36000\b'                -> 0 hits
- grep '192\.168\.1\.3（client'              -> 0 hits (precise)
- grep 'f-stack-client\s*\(\s*192\.168\.1\.3' -> 0 hits

Author: jfb8856606

docs/freebsd_13_to_15_upgrade_spec/zh_cn/cvm-bench-methodology.md

@@ -14,13 +14,17 @@
 
 ## 1. 物理拓扑
 
-| 角色      | 真实 IP（仅保留 D 段） | 文档混淆后    | 硬件 / 软件栈                                                       |
-|-----------|------------------------|---------------|---------------------------------------------------------------------|
-| server    | `x.x.x.176`            | `192.168.1.1` | CVM 16 vCPU AMD EPYC 7K62，virtio_net 00:09.0 + DPDK 23.11.5 + F-Stack |
-| client    | `x.x.x.67`             | `192.168.1.2` | CVM，virtio_net，运行 sshd + wrk / curl / redis-benchmark           |
-| 备用 client | `x.x.x.87`           | `192.168.1.3` | （某些场景下的第二注入端，不常用）                                  |
+| 角色          | 真实 IP（仅保留 D 段） | 文档混淆后    | 硬件 / 软件栈                                                       |
+|---------------|------------------------|---------------|---------------------------------------------------------------------|
+| server 数据面 | `x.x.x.176`            | `192.168.1.1` | server CVM 16 vCPU AMD EPYC 7K62 的弹性网卡，被 DPDK PMD 接管 → F-Stack 协议栈 |
+| server 控制面 | `x.x.x.87`             | `192.168.1.3` | server 同机第二块网卡（未被 DPDK 接管，仍归 kernel），AI AGENT 通过此 IP 与 client 进行 ssh 通信 |
+| client        | `x.x.x.67`             | `192.168.1.2` | CVM，virtio_net，运行 sshd + wrk / curl / redis-benchmark           |
 
-**Server NIC** 必须由 DPDK PMD 接管，kernel 不再持有 IPv4 路径；所有 server 数据面流量直送 F-Stack 协议栈，绕过 Linux 的 conntrack / tcp_ipv4 / sk_buff。
+**控制面 vs 数据面分离**（双 NIC + 单网卡架构）：
+- 控制面（带外）：AI AGENT (本机) ── ssh ──> server 控制面 NIC (`x.x.x.87`) ──> client (`x.x.x.67`) sshd
+- 数据面（带内）：client 注入工具 ──> server 数据面 NIC (`x.x.x.176`，DPDK PMD) ──> F-Stack 协议栈
+
+server 数据面 NIC 必须由 DPDK PMD 接管（kernel 不再持有 IPv4 路径）；server 控制面 NIC 必须保留给 kernel，否则 AI AGENT 无法 ssh 到 client。
 
 **Client 侧栈二选一**：
 
@@ -31,11 +35,7 @@
 
 栈选择不影响 A/B 结论的相对差异，但绝对吞吐会因栈不同而不同。
 
-**控制面 vs 数据面分离**：
-- 控制面（带外）：AI AGENT --ssh--> client sshd（端口 22 或自定义）
-- 数据面（带内）：client 注入工具 ↔ server F-Stack 协议栈（80/6379 等）
-
-两者互不干扰：ssh 走 kernel 路径（不论 client 是否 F-Stack 旁路），benchmark 数据面则走选定的栈。
+**两面互不干扰**：ssh 走 kernel 路径（server 端经控制面 NIC `x.x.x.87`，client 端不论是否启用 F-Stack 旁路 ssh 都走 kernel）；benchmark 数据面则走选定的栈，与 ssh 控制面物理上隔离在不同的 NIC 通道上。
 
 ---
 

docs/freebsd_13_to_15_upgrade_spec/zh_cn/cvm-bench-methodology.svg

@@ -207,7 +207,7 @@ ff_veth_setaddr → socreate(AF_INET) → ifioctl(SIOCAIFADDR)
 
 ## 12. Phase 3 (端到端联通 + 压测基线 — 含 badfileops 修复) — 2026-06-02 19:50
 
-承接 Phase 2 验收完成，进入端到端跨机验证阶段：本机 192.168.1.1 作 F-Stack server，f-stack-client (192.168.1.3) 作压测客户端，通过 ssh 远程触发 curl / wrk。
+承接 Phase 2 验收完成，进入端到端跨机验证阶段：本机 192.168.1.1（server 数据面）作 F-Stack server，f-stack-client (192.168.1.2) 作压测客户端，AI AGENT 通过 server 控制面 192.168.1.3 经 ssh 远程触发 curl / wrk。
 
 ### 12.1 触发场景与现象
 
@@ -482,7 +482,7 @@ const struct fileops badfileops = {0};
 ### 12.12.1 范围决策与方法
 - 范围：仅 15.0 单边 smoke + wrk T2 一次（T1 5s warmup 用于稳态）
 - 不做 13.0 对比、不做 perf flamegraph（用户决策 Q1=C）
-- 复用 §12.10 同一 lcore=4、端口 80、客户端 wrk binary `/tmp/wrk/wrk`、IP 混淆为 192.168.1.1（server）/ 192.168.1.3（client）
+- 复用 §12.10 同一 lcore=4、端口 80、客户端 wrk binary `/tmp/wrk/wrk`、IP 混淆为 192.168.1.1（server 数据面）/ 192.168.1.2（client）/ 192.168.1.3（server 控制面，AI AGENT ssh 出口）
 
 ### 12.12.2 启动与端口绑定
 - 二进制：`/data/workspace/f-stack/example/helloworld_epoll` (27,934,872 B)，由主树 15.0 runtime-fix-done lib 链接
@@ -599,7 +599,7 @@ const struct fileops badfileops = {0};
 - 范围（与 §12.13 nginx 同套"类似方法"）：双树 build → redis-benchmark T1/T2/T3 同时间窗
 - 工具切换：wrk → **redis-benchmark**（redis 协议专用，stock redis-7.2.7-6.tl4，向下兼容 redis 6.2.6 server）
 - redis-benchmark 与 redis-cli 由 server `dnf install redis` 安装后 scp 到 client `/tmp/`（fstack-linked 版本不能在 client 普通环境运行，会因 ff_init 失败 segfault）
-- IP 混淆从源头：192.168.1.1（server）/ 192.168.1.3（client），:22 替代 :<实际ssh端口>
+- IP 混淆从源头：192.168.1.1（server 数据面）/ 192.168.1.2（client）/ 192.168.1.3（server 控制面，AI AGENT ssh 出口），:22 替代 :<实际ssh端口>
 
 ### 12.14.2 规约合规说明
 - redis 自带 Makefile 的 `make install` 会触发 install -m → 规避：仅 `make`，手动 `mkdir + cp -p` 部署到独立 prefix