transport: probe Windows named pipes without a Tokio reactor

[gdamprint-cmyk]

Closes #1524

Problem

is_socket_path and remove_socket are synchronous by contract, so a caller can
ask "is a daemon already listening?" without owning a runtime. Both nevertheless
opened the pipe through tokio's named-pipe client, which registers the handle
with the ambient reactor:

thread '<unnamed>' panicked at tokio-1.49.0/src/net/windows/named_pipe.rs:1005
there is no reactor running, must be called from the context of a Tokio 1.x runtime

The panic happens on the open call itself, before any result is known, so it
is not specific to a missing or busy endpoint. Any embedder that drives the SDK
from plain std::threads takes this path, which is what Jcode Desktop's bridge
processes do.

It also cannot be caught off Windows: windows.rs compiles only on Windows, and
the path is only reached from a reactor-less thread.

Fix

Both probes go through one probe_pipe helper built on std::fs::OpenOptions,
the same approach SyncStream::connect in this file already uses:

fn probe_pipe(pipe_name: &str) -> io::Result<()> {
    std::fs::OpenOptions::new()
        .read(true)
        .write(true)
        .open(pipe_name)
        .map(|_handle| ())
}

ERROR_PIPE_BUSY still maps to "a server is listening", so
busy_pipe_is_reported_as_a_live_socket_path is unchanged and keeps passing.

One file, no API change, no behavioural change on the success and busy paths.

Test

sync_pipe_probes_do_not_panic_without_a_tokio_reactor binds a real listener
inside a #[tokio::test] runtime and then probes it from a std::thread that
deliberately has no runtime. That split is the situation in the bug: the server
owns a runtime, the synchronous probes do not.

Edge cases and the two ways this test can lie

Both were hit while writing it, and both are worth stating because either one
yields a test that passes with and without the fix:

• Probe a pipe that is actually bound. On an absent path the open fails
  before tokio reaches the reactor registration, so nothing panics. The first
  version of this test did exactly that and passed against the unfixed code.
• Bind the listener under a runtime. A plain #[test] cannot call
  Listener::bind at all, so the panic then happens during setup rather than in
  the code under test, which makes the test fail for the wrong reason.

With the fix reverted, the failure is the reactor panic in the spawned
thread (thread '<unnamed>'), not in the setup, and the other six tests in
the crate pass in both states. That is the evidence the test isolates this
defect rather than merely noticing that something changed.

cargo test -p jcode-transport --lib is 7 passed, 0 failed. cargo fmt --check
is clean for the crate.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Changes how Windows named pipes are probed for availability.

No outstanding findings block merging.

Summary

The Windows regression test now gives remove_socket a separately bound named pipe, addressing the previously reported coverage gap. No new issues were identified.

_{Reviews (2) · Last reviewed commit: "transport: probe remove_socket on its ow..."}

[gdamprint-cmyk]

Correct, and the test was weaker than it claimed.

is_socket_path and remove_socket were probing the same single-instance
listener. Probing consumes the only available instance of a Windows named pipe,
so the second open can return ERROR_PIPE_BUSY and return an error without ever
reaching the code under test. A reverted ClientOptions::open inside
remove_socket could therefore have passed while the test was green.

Fixed in 6c83e653b: the test now binds a second, separate pipe for
remove_socket, so each probe hits a freshly available instance and each is
covered independently.

The load-bearing proof is repeated after the change rather than reused, because
the earlier proof was for the earlier version of the test. With probe_pipe
reverted to ClientOptions::open,
sync_pipe_probes_do_not_panic_without_a_tokio_reactor is the only one of the
seven that fails, and it fails with

there is no reactor running, must be called from the context of a Tokio 1.x runtime

in the spawned thread, not in the setup. With the fix in place all seven pass
and cargo fmt --check is clean.