[BUG] Last Release (3.2.0) is broken. SenderOptions.addr is ignored, causing fallback to localhost:9000 and IngressError

Start by comparing the SenderOptions and Sender.New behavior between client versions 3.2.0 and 3.1.1, focusing on how addr is transferred to the sender connection. Reproduce the supplied .NET 8.0 example and verify that a flush connects to 192.168.0.218:9000 instead of localhost:9000.

Description: I am encountering an issue where the SenderOptions.addr property seems to be ignored when initializing a Sender. Even though I provide a valid remote IP address in the options, the client attempts to connect to localhost:9000 (the default), resulting in a ServerFlushError.

I verified in the debugger that SenderOptions.addr is correctly set to my remote endpoint (192.168.0.218:9000) before calling Sender.New(), but the exception message explicitly states it cannot connect to localhost.

Steps to Reproduce:

Create a SenderOptions object specifying a remote address in addr.
Initialize the sender via Sender.New(options).
Attempt to send data (or wait for auto-flush).

Code Sample:

var endpoint = "192.168.0.218:9000"; // Valid remote QuestDB instance
var options = new SenderOptions
{
    addr = endpoint, 
    init_buf_size = 104_857_600,
    auto_flush = QuestDB.Enums.AutoFlushType.on,
    auto_flush_interval = TimeSpan.FromSeconds(5),
    max_buf_size = 838_860_800,
    retry_timeout = TimeSpan.FromSeconds(5)
    // username and password set if required
};

// The sender ignores 'endpoint' and tries to connect to localhost:9000
using var sender = Sender.New(options); 

// Operations causing the flush triggers the error

Expected Behavior: The client should connect to the IP address specified in SenderOptions.addr (192.168.0.218:9000).

Actual Behavior: The client throws an exception indicating it tried to connect to localhost:
QuestDB.Utils.IngressError: 'ServerFlushError : Cannot connect to localhost:9000'

Environment:
QuestDB Client Version: 3.2.0
Target Framework: .NET 8.0
OS: Windows 10

Regression Confirmation: I have verified that this issue does not exist in version 3.1.1. When downgrading the library to 3.1.1, the exact same code and SenderOptions configuration work perfectly, and the client successfully connects to the remote address (192.168.0.218:9000). This suggests the problem was introduced in the recent update.