test: validate native TLS on Linux

PERFORMANCE.md

@@ -54,6 +54,12 @@ go run ./internal/perfcheck --duration 2s --count 3 --output /tmp/goOmniPerf.jso
 
 ## benchmark 口径修正
 
+## TLS 验收记录
+
+macOS arm64 本机的 5 秒 TLS 矩阵见 [tlsBaseline.json](performance/tlsBaseline.json)：1 / 32 / 128 并发和 128 / 1,024 条空闲连接均为 0 错误；native 在 128 并发约 114,232 req/s，1,024 条空闲 TLS 连接的服务端堆增量约 8.94 MiB，连接关闭后 goroutine 回到基线。
+
+Linux arm64 容器使用 Go 1.25.14、GOMAXPROCS=4 运行 3 秒矩阵，见 [tlsBaselineLinux.json](performance/tlsBaselineLinux.json)：1 / 32 / 128 并发和 128 / 512 条空闲连接均为 0 错误；native 在 128 并发约 99,876 req/s，512 条空闲 TLS 连接的服务端堆增量约 4.47 MiB，连接关闭后 goroutine 回到基线。容器验证同时通过全量 race、vet、build。
+
 `BenchmarkTransportTCPApplicationRequest/{nethttp,native}/concurrency{1,32,128}` 使用同一测试入口、客户端、应用与响应检查。原先独立的 `BenchmarkNativeApplicationRequest` 已合并，避免两个入口配置漂移。`verifyPerformance.py` 会一并运行。
 
 并行 benchmark 的 **`ns/op` 是总经过时间除以请求数，反映吞吐成本，不是单请求延迟**。`B/op` / `allocs/op` 统计同一进程中的客户端与服务端总分配。此前报告的 native 15.4–16.7 µs/op、约 7.8 KB/op、100 allocs/op 应按这个含义理解，不能作为服务端延迟或独立内存指标。