fix(channel): M41 r1 复审三条 —— telegram 构造分支、QQ 改 MaskQuery、删两处死上限

P2-1 telegram doJSON 的**请求构造**失败分支：http.NewRequestWithContext 解析失败的
err 同样是 *url.Error（里面是整条 /bot<token>/… 地址），而 poll.go 的 long poll
failed 会原样落日志。改成与传输层分支同形：trace.HostOf(endpoint) + callCause。

P2-2 qq_obv11 connectClient 的成功 INFO 从 maskAccessTokenQuery 换成
trace.MaskQuery：后者认得 access%5Ftoken / token / api_key / 签名参数 / userinfo，
且保留 EscapedPath（路径可读）与不截断。maskAccessTokenQuery 仍被
sanitizeConnectReason 使用，未成死代码。

P2-3 删掉 maxEnvelopeMessageRunes / maxDescriptionRunes（各 200）：trace.RedactText
内部已 truncate 到 maxSummaryRunes=80，这两层永不命中，注释口径与实际不符。改为
直接 return trace.RedactText(压平空白)，注释写明 80 rune 由 RedactText 负责。

用例（全部变异打红，逐条验证）：telegram 构造分支 token、QQ 八形态凭据矩阵
（含四种 maskAccessTokenQuery 漏掉的形态 + 路径可读反向断言）、两处 80 rune 上限。

internal/channel/adapter/httpclient/leak_test.go

@@ -145,3 +145,28 @@ func TestGetJSON_UserinfoNeverEntersError(t *testing.T) {
 		t.Fatalf("user:pass@ 进了错误：%v", err)
 	}
 }
+
+// TestDoJSON_EnvelopeMessageIsBoundedByRedactText 钉住长度口径：信封 message 只有一道
+// 清洗（trace.RedactText，80 rune + 省略号）。本片曾按 200 rune 自己再截一刀，那层
+// 永远命中不了 —— 这条用例让「到底哪一层在截」变成可断言的事实。
+func TestDoJSON_EnvelopeMessageIsBoundedByRedactText(t *testing.T) {
+	t.Parallel()
+	long := strings.Repeat("a", 300)
+	srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		w.WriteHeader(http.StatusBadRequest)
+		_, _ = w.Write([]byte(`{"code":40101,"message":"` + long + `","data":null}`))
+	}))
+	defer srv.Close()
+
+	c := New(WithBaseURL(srv.URL), WithHTTPClient(srv.Client()), WithLogger(discardLogger()))
+	_, err := c.DoJSON(context.Background(), http.MethodGet, "/gateway/index", nil)
+	if err == nil {
+		t.Fatal("401 却报成功")
+	}
+	if !strings.Contains(err.Error(), strings.Repeat("a", 80)+"…") {
+		t.Fatalf("信封 message 没有按 80 rune 截断：%v", err)
+	}
+	if strings.Contains(err.Error(), strings.Repeat("a", 81)) {
+		t.Fatalf("信封 message 超过了 80 rune 上限：%v", err)
+	}
+}