feat(perf): 容量压测器 + 平台天花板实测曲线

cmd/loadtest：闭环加压器，阶梯并发，经 SSE 流检测完成（非轮询，避免轮询放大把网关
压成假瓶颈），输出吞吐 + 延迟分位。配套两个 benchmark 开关：
- dispatcher LLM_FORCE_STUB=1 + LLM_STUB_TTFT_MS/INTERTOKEN_MS=0：绕开真实 LLM 推理，
  量平台自身全链路天花板（不烧 token、不被模型节奏掩盖）。
- gateway RATE_LIMIT_PER_MIN 可配（缺省 120）：压测放开限流。

实测（单 dispatcher、并发64、stub）：
- 单任务纯平台开销 ~42ms；吞吐峰值 ~110 全链路任务/秒（饱和点 并发32–64）；
  并发128 优雅降速，256 硬崩。
- 吞吐瓶颈不是 DB 连接数（池 25→80 吞吐不变），是每任务多跳管线综合成本；
  256 崩根因为 DSN 用 localhost、pgx 每连接解析 → 连接churn致 DNS 取消（易修）。
- 关键判断：平台 42ms ≪ LLM 秒级出答案，平台不是瓶颈、GPU 才是；横向拆服务喂满 GPU 集群
  的意义成立。细节与曲线见 project_analysis「容量实测」。

stub 延迟改 env 可配（默认值不变）；不影响线上路径。dispatcher+gateway build/vet/test 全绿。

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

sundynix-gateway/internal/middleware/guardrail.go

@@ -42,9 +42,9 @@ func Guardrail() gin.HandlerFunc {
 }
 
 // RateLimit 基于 Redis 的会话级限流（按客户端 IP，每分钟上限）。
-// Redis 降级时 Allow 始终放行，不阻断业务。
+// 上限经 RATE_LIMIT_PER_MIN 配置（缺省 120）；压测可调高。Redis 降级时始终放行，不阻断业务。
 func RateLimit(cache *store.Redis) gin.HandlerFunc {
-	const perMinute = 120
+	perMinute := int64(envInt("RATE_LIMIT_PER_MIN", 120))
 	return func(c *gin.Context) {
 		ok, _ := cache.Allow(c.Request.Context(), c.ClientIP(), perMinute, time.Minute)
 		if !ok {