fix: transport scheduling flow control

[nange]

背景

对 config/types.go 默认参数的审查发现了三个影响实际吞吐/行为的问题：

1. 纯 bulk 负载下连接池永不扩容：grow() 对 bulk 流使用 [prioritySlots, live) 范围，
   当 live < prioritySlots 时该范围为空直接返回，而连接池只能靠 priority 流（80/443 等端口）
   扩容。BT/下载器等纯下载场景会永远停在初始 2 条连接上，heavy 流隔离、多连接抗限速全部失效。
2. 上行流控窗口过小：服务端每流接收窗口 256KB（仅为 stdlib 默认的 1/4），
   HTTP/2 单流上行吞吐 ≈ 窗口/RTT，300ms RTT 链路上单流上传被硬性封顶在 ~6.8Mbps。
3. 连接字节轮换只统计下行：connBytesRecv 只在 trackRead 累加，上传型流量永不触发
   conn_max_bytes 轮换，而中间盒按字节限速对上行同样生效。

修改

• transport/http2/scheduler.go：新增 growRange()，bulk 范围为空时回退到全量
  [0, live) 范围按 bulkThreshold 判定，与 pick() 的调度行为对齐；首查与锁内复查统一。
• config/types.go + server/server.go：服务端上行流控窗口每流 256KB→1MB、
  每连接 1MB→4MB；抽取 buildHTTPServer() 供测试直接构造。
• transport/http2/：connBytesRecv 重命名为 connBytes，trackWrite/trackRead
  双向累加；bytesRecv 仍只统计下行，降级检测的吞吐采样语义不变。
• 顺便修复了，在macOS上，配置相对路径，找不到文件的问题。

测试

• TestGrowBulkOnlyWorkloadGrowsPool 等 3 个调度器用例：纯 bulk 负载逐条扩容、
  bulk 范围非空后使用专属范围、priority 行为回归。
• TestBuildHTTPServerUploadFlowControl + TestServerUploadFlowControlWindowsOnWire：
  以字面量下限断言窗口配置，并在真实 TLS+h2 连接上解析服务端 SETTINGS /
  WINDOW_UPDATE 验证对端实际看到的窗口。
• TestHTTP2Stream_ConnBytesCountsBothDirections 等：上行计入轮换字节、下行吞吐采样不混入、
  nil-slot 守卫。

验证

• go build ./...、go vet、go test ./...、make lint 全部通过。

影响与风险

• 服务端每连接接收窗口上限 1MB→4MB（懒分配），单个高负载客户端 18 连接最坏多占 ~54MB 内存。
• 纯下载场景下客户端会建立更多到服务器的连接（预期行为，符合 18 连接上限设计）。