fix(store): PG DSN 默认用 127.0.0.1 免每连接 DNS 解析；订正压测报告 C=256 归因

DSN 由 localhost 改 127.0.0.1（gateway + mcp-go）：pgx 每新建连接解析一次主机名，
高并发连接池扩容时省掉这层 DNS 开销与一类失败模式。

诚实订正：复测发现 DSN 改完 C=256 仍 0 完成（错误从 lookup localhost 变 dial 127.0.0.1 canceled）。
故 C=256 的「停摆」根因不是 DNS，而是单节点在 256 并发下整体饱和（任务排队 + 每任务 3 次 PG
状态写 + 网关 handler 顶不住），属单节点容量上限、非 bug；C≤128 优雅可用，正解是横向扩。
LOAD_TEST_REPORT §4.3/§6 与 project_analysis 容量实测已据实更新。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

LOAD_TEST_REPORT.md

@@ -57,10 +57,18 @@
 每个任务要走的**一长串同步跳数**（JetStream 落盘 + 多次 NATS 回写 + Redis 录制 + 多次 PG 写）的累加成本。
 要把单节点吞吐再往上抬，得减少每任务的同步跳数（如状态写批量化/异步化），而非简单加资源。
 
-### 4.3 C=256 硬崩的根因（易修）
-网关日志：`failed to connect ... lookup localhost: operation was canceled`。
-DSN 用了主机名 `localhost`，pgx 每新建一条连接都做一次 DNS 解析；极端并发下连接抖动 → 大量 DNS 查询
-在请求超时里被取消 → 雪崩。**修法简单**：DSN 改 `127.0.0.1`（免 DNS）+ 连接复用调优。属配置级修复，非架构问题。
+### 4.3 C=256 的「停摆」：单节点饱和，非 bug
+现象：C=256 在 10s 窗口内 0 完成。
+
+初判曾归因于 DSN 用 `localhost` 致 pgx 每连接 DNS 解析、极端并发下 DNS 查询被取消。
+**已把 DSN 改为 `127.0.0.1`**（确实消除了 DNS 那一层 + 每连接解析开销，是值得的卫生改进），
+但复测 C=256 仍 0 完成 —— 错误从 `lookup localhost` 变成 `dial tcp 127.0.0.1:5432: operation was canceled`。
+
+**真实根因**：单节点在 256 并发下整体饱和 —— 任务排队 + PG 状态写路径（每任务 3 写、池 25）+ 网关
+handler/连接 顶不住，单任务延迟超过测试窗口，故窗口内零完成（那些 "canceled" 是窗口到点取消在途请求的尾部噪声）。
+**这不是要修的 bug，是单节点容量上限的表现**：C≤128 优雅降速可用，256 已远超单 dispatcher 的 ~110/s 甜区。
+**正解是横向扩**（加 dispatcher 副本，队列组自动分摊）——正好印证 §4.4 的判断。
+单节点要再抬高，则需状态写批量/异步化（降低每任务的同步 PG 跳数）。
 
 ### 4.4 核心判断：平台不是瓶颈，GPU 才是
 - 平台固有开销 **~42ms / 任务**。
@@ -96,11 +104,11 @@ DSN 用了主机名 `localhost`，pgx 每新建一条连接都做一次 DNS 解
 ---
 
 ## 6. 待补（后续）
+- ✅ DSN `localhost → 127.0.0.1`（已修，消除每连接 DNS 解析；但不解决 §4.3 的单节点饱和）。
 - 长稳压测（小时级）：看内存 / 文件句柄 / goroutine 是否泄漏。
 - 真实 LLM 端到端容量：受在线 provider 限流，需自部署模型后再测。
-- DSN `localhost → 127.0.0.1`（顺手修，消除 §4.3 崩溃）。
 - 状态写批量/异步化探索（抬高单节点天花板）。
-- 多副本 + NATS 集群下的容量复测。
+- 多副本 + NATS 集群下的容量复测（验证横向扩是否线性）。
 
 ---