docs: record local DDS bootstrap finding

docs/crucial_change/2026-07-23-fastdds-164-network-change.md

@@ -1060,3 +1060,15 @@ unset _wsl_dds_profile
   - `wlan0` 的 Domain 22 抓包：`0 packets captured`。
   - `.210` SSH 返回 `management-link-ok`。
 - 结论：对从专用环境启动的 Domain 22 participant，跨主机 DDS 数据只使用 WSL `.151` 与 RDKx5 `.164`，`.210` 保持为管理链路。
+
+### 实施偏差：为同主机多进程增加本机 bootstrap peer
+
+- 发现时间：2026-07-23 `obstacle_nav2` 最小实际验证。
+- 安全条件：使用专用 RDK 环境启动 `enable_motion:=false`，底盘速度被重映射到 `/cmd_vel_hardware_disabled`，未发布导航目标。
+- 现象：底盘、雷达、`obstacle_scanner` 和 Nav2 进程均启动，但 lifecycle manager 持续输出 `Waiting for service controller_server/get_state...`；WSL 只能看到 `/scan` 等基础话题，未看到 `/obstacles` 和 costmap。
+- 根因：关闭 SPDP 多播后，RDK profile 的 initial peer 只有远端 WSL `.151`。同一 RDK 上的多个 participant 没有本机单播 bootstrap peer，SHM transport 本身不替代 participant discovery。
+- 修正：
+  - RDK initial peer 同时包含本机 `.164` 和对端 `.151`。
+  - WSL initial peer 同时包含本机 `.151` 和对端 `.164`，保证 WSL 现有软件由多个 participant 组成时也能本机发现。
+- 范围：只在两个 Fast DDS XML 的 `<initialPeersList>` 中各增加一个本机 locator；继续保持 `avoid_builtin_multicast=true` 和接口白名单。
+- 必要复测：Nav2 lifecycle 完成配置/激活，WSL 可见 `/obstacles` 与 local/global costmap，`.210` Domain 22 抓包仍为零。