Problem

The kt-kernel CLI checks whether a server port is available before saving or reusing an interactive run configuration. That check currently treats a failed TCP client connection as proof that the port is available.

The affected flow is:

kt run interactive setup
  -> kt_kernel.cli.utils.run_interactive.configure_host_and_port(...)
    -> kt_kernel.cli.utils.port_checker.is_port_available(...)
    -> kt_kernel.cli.utils.port_checker.find_available_port(...)

is_port_available() is used as a pre-launch guard: if it returns True, the CLI can print that the port is available, keep the selected host/port in the run configuration, or suggest that port as the next usable option.

However, the old implementation used socket.connect_ex() to probe the port. connect_ex() answers a different question: can a client establish a connection to a server that is already listening at this address? It does not answer the server-side question the CLI needs here: can the launch process bind this local host/port?

A port can already be reserved with bind() while no process is listening on it yet. In that state, connect_ex() fails with a connection error, and the helper incorrectly interprets that failed connection as “the port is available”. The later server launch can then fail when it performs its real bind step.

Reproduction Shape

A minimal reproduction is to bind an ephemeral TCP port without calling listen():

holder = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
holder.bind(("127.0.0.1", 0))
port = holder.getsockname()[1]

print(is_port_available("127.0.0.1", port))
print(find_available_port("127.0.0.1", port, max_attempts=1))

Before the fix, this reports the held port as available and can suggest the same port again.

Expected Behavior

A port that is already bound should be treated as unavailable, even if no server is currently accepting client connections on it.

The availability helper should check the same operation that the server launch will need later: a local bind() on the requested host and port.

Impact

The interactive CLI can accept or suggest a port that looks available during setup but fails later during the actual server startup. This turns a pre-launch validation step into a false sense of safety and pushes the failure later into the runtime launch path.

Proposed Fix

Use a short-lived bind() attempt in the port availability helper, and keep find_available_port() delegating to that corrected helper.

A draft PR with this fix is available at #2071.