Windows binary fails immediately on `n new` — `creack/pty` is unsupported on Windows

Summary

The published claude-squad_1.0.17_windows_amd64.zip binary builds and launches, but creating any new session fails instantly with:

failed to start new session: error starting tmux session: unsupported

The TUI itself renders, cs version works, the menu navigates — but the core feature (spawning an agent under a tmux session) is unreachable on native Windows.

Root cause

session/tmux/pty.go calls pty.Start(cmd) from github.com/creack/pty. On any non-Unix GOOS, creack/pty falls back to pty_unsupported.go, whose open() returns ErrUnsupported. The Go cross-build for windows/amd64 succeeds because the stub compiles cleanly, so GoReleaser ships a binary that has no functional PTY path.

Reference: https://github.com/creack/pty/blob/master/pty_unsupported.go

Reproduction

1. Windows 11 native (no WSL).
2. Download claude-squad_1.0.17_windows_amd64.zip from the v1.0.17 release.
3. Extract claude-squad.exe, run from a git repo in PowerShell or Git Bash.
4. Press n to create a new session.
5. Error appears immediately, no tmux command is ever executed.

Environment

• OS: Windows 11 Pro 26220
• claude-squad: v1.0.17 (official Windows release)
• Shell tested: PowerShell 7, Git Bash 2.x
• tmux: marlocarlo.psmux 3.3.1 (a PowerShell-based tmux-compatible multiplexer, since real tmux has no native Windows port). Note: psmux is not invoked at all in this bug — the failure happens inside pty.Start() before any tmux command runs.
• Verified the failure is upstream of tmux by reading session/tmux/pty.go and the linked creack/pty stub.

Suggested fix

Replace github.com/creack/pty with a cross-platform PTY library that supports Windows ConPTY. Candidates:

• github.com/aymanbagabas/go-pty — by Charm (same org as bubbletea, which claude-squad already depends on). Designed as a creack/pty drop-in with ConPTY support.
• github.com/UserExistsError/conpty — pure Go ConPTY wrapper, lower-level.

Happy to contribute a PR if a maintainer can confirm the preferred direction (especially around the *os.File return type, which doesn't map cleanly onto a Windows HANDLE — the abstraction in Pty.Start() may need to widen to an io.ReadWriteCloser).

Workarounds for other Windows users finding this

Currently none. The Windows binary ships but is non-functional for the tool's primary purpose. The README does not mention Windows support status.