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>

project_analysis.md

@@ -235,8 +235,8 @@ dispatcher 开 `LLM_FORCE_STUB=1 LLM_STUB_*_MS=0` 绕开真实 LLM 推理，量*
 1. **单节点平台天花板 ≈ 110 全链路任务/秒**，单任务固有开销 ~42ms，饱和点 ~并发 32–64。
 2. **吞吐瓶颈不是 DB 连接数**（池 25→80 吞吐不变），而是每任务多跳管线（JetStream fsync + 多次
    NATS 回写 + Redis 录制 + 3 次 PG 状态写）的综合成本。
-3. **C=256 硬崩**根因：DSN 用 `localhost`，pgx 每新建连接解析一次，极端并发下连接churn致 DNS 取消
-   → 易修（DSN 换 `127.0.0.1` / 连接复用）。
+3. **C=256 停摆**是单节点饱和（任务排队 + PG 状态写 + 网关 handler 顶不住），非 bug；C≤128 优雅可用。
+   DSN 已由 `localhost` 改 `127.0.0.1`（消除每连接 DNS 解析，卫生改进，但不解决饱和）。正解是横向扩。
 4. **关键判断**：平台开销 42ms ≪ 真实 LLM 出一轮答案的秒级延迟，**平台不是瓶颈，GPU 才是**。
    单 GPU 跑 Qwen 32B 约出几十轮/秒，远低于平台的 ~110/s → 横向拆服务（队列组多副本喂满 GPU 集群）
    的意义成立；要提总吞吐应加 dispatcher 副本与 GPU，而非优化平台代码。