Incorrect timeout

When setting a session timeout, the behaviour seems incorrect! Consider this code that connects via ssh and runs sleep 30 && echo DONE to sleep for 30 seconds:

    let username = "...";
    let ip = "...";
    let password = "...";

    let timeout_ms = 15_000;
    let command = "sleep 30 && echo DONE"

    let tcp = std::net::TcpStream::connect(format!("{ip}:22"))?;
    let mut sess = Session::new()?;
    sess.set_timeout(timeout_ms);
    sess.set_tcp_stream(tcp);
    sess.handshake()?;
    sess.userauth_password(&username, &password)?;
    if !sess.authenticated() {
        return Err(anyhow!("Failed to connect by SSH"));
    }

    // Connect channel in exec mode.
    let mut channel = sess.channel_session()?;
    channel.handle_extended_data(ssh2::ExtendedData::Merge)?;
    println!("running command: {command}");
    channel.exec(command)?;
    let mut output = String::new();
    channel.read_to_string(&mut output)?;
    channel.close()?;
    channel.wait_close()?;
    let exit_status = channel.exit_status()?;

    sess.disconnect(
        Some(DisconnectCode::ByApplication),
        "Finished Running Script",
        None,
    )?;

    println!("SUCCESS");
    println!("exit code: {exit_status}");
    println!("output:\n{output}");

I expect the session to timeout after 15 seconds, but instead it times out after 30 seconds! If instead we have timeout_ms = 5_000 then it times out after 15 seconds. From my experimenting I think the current (unexpected) behaviour is as follows:

If the command blocks for duation t and t < timeout then return Ok
If the command blocks for duation t and t > 3*timeout then return a timeout error at time 3*timeout.
If the command blocks for duation t and timeout < t < 3*timeout_ms then return a timeout error at time t

I'm running on windows and with ssh2-0.9.4

Start by reproducing the reported behavior with the Rust SSH example in the issue, varying timeout_ms and the duration of the remote sleep command. Trace how the session timeout applies during channel execution and verify that the observed timeout occurs at the configured limit rather than at a multiple of it.