tls 1.2 decode error for https://cdn.kernel.org

[Allar]

Zig Version

0.14.0-dev.2198+e5f5229fd

Steps to Reproduce and Observed Behavior

I'm using this function to download files, which is probably not ideal but it seems to work for the most part.

https://github.com/torvalds/linux/archive/refs/tags/v6.11.tar.gz works successfully
https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.11.7.tar.xz results in a tls decode error

It would be nice to be able to support downloading from cdn.kernel.org imo.

Opening a specific issue for this url as per #14172 (comment)

pub fn downloadFile(allocator: std.mem.Allocator, uri: std.Uri, destSubPath: []const u8) !void {
    var client: std.http.Client = .{ .allocator = allocator };
    defer client.deinit();

    try client.ca_bundle.rescan(allocator);

    var serverHeaderBuffer: [8192]u8 = undefined;

    var req = try client.open(.GET, uri, .{
        .server_header_buffer = &serverHeaderBuffer,
    });
    defer req.deinit();

    try req.send();
    try req.finish();

    std.log.info("downloading {}", .{uri});

    try req.wait();

    switch (req.response.status) {
        .ok => {},
        else => {
            return FetchError.BadResponse;
        },
    }

    const bodyBufferSize = 4096;

    // create br with bodyBufferSize?
    var br = std.io.bufferedReader(req.reader());
    const r = br.reader();

    var bodyBuf: [bodyBufferSize]u8 = undefined;

    var readBytes = try r.read(&bodyBuf);

    if (readBytes <= 0) {
        return FetchError.NoData;
    }

    const file = try std.fs.cwd().createFile(destSubPath, .{});
    defer file.close();

    var bw = std.io.bufferedWriter(file.writer());

    while (readBytes > 0) {
        _ = try bw.write(bodyBuf[0..readBytes]);
        readBytes = try r.read(&bodyBuf);
    }

    try bw.flush();
}

Expected Behavior

For the http client to negotiate and download the file using the kernel.org url as it does for the github url.

[ianic]

When connecting to cdn.kernel.org server is choosing:
tls version: tls_1_2
cipher: ECDHE_RSA_WITH_AES_128_GCM_SHA256
named group: x25519
signature scheme: rsa_pss_rsae_sha256

For this case named group is interesting because in zig implementation client key exchange message is always using public key from secp256r1 named group. If I change that line to:

array(u24, u8, array(u8, u8, key_share.x25519_kp.public_key)));

than it works for cdn.kernel.org (but breaks all other named groups).
Key exchange message should use public key based on the server chosen named group.

Some other domains which are also affected:
imgur.com
forbes.com
independent.co.uk
etsy.com
fastly.net