fix(cli): make the command-line client work on Windows

Its suite had only run on Linux. On Windows, against a real hub and node and
from the installed meshbay-cli.exe:

- secrets.enc was written in text mode (os.open without O_BINARY): every 0x0A
  of the ciphertext became CR LF and the saved session "does not open with
  its key" on the next run.
- isatty() is true for NUL, so a script run with `< NUL` or by the Task
  Scheduler was asked questions instead of told to pass --yes;
  output.terminal() checks for a real console.
- Ctrl+C waited for the selector loop's next timer, up to half a minute in
  `chat --follow`; the loop now points the signal wakeup at its self-pipe,
  as the proactor does.
- Right-click copy and paste raised: asyncio cannot start a process on the
  selector loop; the clipboard tool runs in a thread.
- Tab completion of remote paths ran on the default (proactor) loop, which
  never opens a node, and wrote in the locale encoding; the PowerShell script
  now reads it as UTF-8.
- `get -R` into a folder past MAX_PATH died with a traceback; get, put, the
  resume file and the interactive mode use the extended form at each disk
  call, as the node does.
- `groups` showed a SQLite hub's naive UTC time as local time.

The opt-in end-to-end suite now runs on Windows (16 tests: Chrome found under
Program Files and started with the real environment, VLC as the player, Ctrl+C
through a console of its own, PowerShell 5.1 completion of an accented name).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 31 insertions, 3 deletions

diff --git a/packages/meshbay-cli/src/meshbay_cli/output.py b/packages/meshbay-cli/src/meshbay_cli/output.py
index d4c0758..1d46981 100644
--- a/packages/meshbay-cli/src/meshbay_cli/output.py
+++ b/packages/meshbay-cli/src/meshbay_cli/output.py
@@ -54,8 +54,36 @@ def columns(names: list[str]) -> str:
     return "\n".join(lines)
 
 
+def terminal(stream) -> bool:
+    """
+    Whether `stream` is a terminal a person sits at. `isatty()` alone is wrong on
+    Windows, where it means "a character device" and so says yes for NUL: a
+    script run with `< NUL`, or by the Task Scheduler, was asked questions it
+    could not answer instead of being told to pass --yes.
+    """
+    try:
+        if not stream.isatty():
+            return False
+    except (AttributeError, ValueError):
+        return False
+    if sys.platform != "win32":
+        return True
+    try:
+        fd = stream.fileno()
+    except (OSError, ValueError):
+        return True                  # not a file at all: take its word
+    import ctypes
+    import msvcrt
+    try:
+        handle = msvcrt.get_osfhandle(fd)
+    except OSError:
+        return False
+    mode = ctypes.c_uint32()
+    return bool(ctypes.windll.kernel32.GetConsoleMode(handle, ctypes.byref(mode)))
+
+
 def is_tty() -> bool:
-    return sys.stdout.isatty()
+    return terminal(sys.stdout)
 
 
 def err(message: str) -> None:
@@ -71,7 +99,7 @@ class Progress:
 
     def __init__(self, arrow: str, *, quiet: bool = False, as_json: bool = False):
         self.arrow = arrow
-        self.live = sys.stderr.isatty() and not quiet and not as_json
+        self.live = terminal(sys.stderr) and not quiet and not as_json
         self.as_json = as_json and not quiet
         self.files_total = 0
         self.files_done = 0
@@ -149,7 +177,7 @@ def confirm(question: str, yes: bool) -> None:
     from .errors import USAGE, CliError
     if yes:
         return
-    if not sys.stdin.isatty():
+    if not terminal(sys.stdin):
         raise CliError(USAGE, f"{question} Not done: there is no terminal to ask on; "
                               "pass --yes to confirm.")
     # On stderr, like every other word to the person: stdout is the result.