Bring Windows persistent shell and SSH resources to Unix parity

[yyjeqhc]

Priority

P1 — Windows capability parity / runtime completeness

This is a planned capability gap, not a correctness bug in the currently advertised Windows contract. Windows Runner currently fails closed for persistent shell and named SSH resources, while Unix Runners support both local persistent shells and Session-bound SSH execution, including remote persistent shells.

Goal

Bring the Windows Runner to functional parity with the existing Unix shell/SSH model without weakening the current boundedness, lifecycle, fencing, or uncertainty contracts.

Current gap

On Unix today:

• open_session_shell / session_shell_exec / status / close manage a real long-lived sh/bash process;
• persistent shell preserves process state such as cwd, exports, functions, umask, and ordinary shell variables;
• named SSH resources support run_shell and run_job with Session/resource/generation binding and pooled authenticated transport;
• a named SSH resource can also back a remote persistent shell;
• timeout recovery, poisoned/lost transitions, bounded output, Session/project lifecycle cleanup, and no-blind-retry semantics are explicit.

On Windows today:

• local persistent shell is intentionally unsupported and fails closed;
• SshConnectionPool::is_available() is false outside Unix, so named SSH resources are unavailable;
• SSH persistent shell is unavailable as a consequence;
• the current persistent-shell implementation relies on Unix process groups, signals, inherited file descriptors, and Unix pipe/control mechanics and therefore cannot simply be enabled with cfg changes.

This issue is separate from #66 and #67. Those issues repair Windows correctness for existing operations; this issue adds capabilities that Windows does not currently advertise.

Proposed stages

1. Windows local persistent shell

   • implement a Windows-native long-lived shell transport, initially for PowerShell/pwsh if that is the canonical Windows shell contract;
   • preserve the shared PersistentShellManager state machine where possible rather than forking lifecycle semantics;
   • provide an explicit completion/control channel that cannot collide with ordinary stdout/stderr;
   • preserve bounded stdout/stderr, command serialization, timeout recovery, poisoned/lost handling, idle/session/project/Runner cleanup, and one-active-shell-per-Session semantics;
   • do not claim restart recovery or PTY/full-terminal support.

2. Windows named SSH resources

   • support the Runner host's OpenSSH client without storing credentials or SSH configuration in Session state;
   • preserve Session/resource/config-generation binding and fail closed when the configured resource changes;
   • preserve definite-not-started vs uncertain-post-dispatch semantics and never blind-retry a possibly delivered remote command;
   • choose a Windows-appropriate transport-reuse mechanism rather than assuming Unix control-socket mechanics are portable.

3. Windows SSH persistent shell

   • reuse the shared persistent-shell state machine through a Windows-capable SSH transport;
   • preserve remote cwd precedence and immutable resource/generation binding captured at open;
   • no silent local fallback when SSH capability or binding is unavailable.

Preserve

• Server/Runner authorization and exact project/Session binding.
• Existing raw-shell policy and authored command bounds.
• Bounded output and bounded timeout/recovery behavior.
• not_started vs outcome_unknown / uncertain remote-delivery semantics.
• Config-generation fencing for named SSH resources.
• No credentials, host configuration, private keys, passwords, or connection state persisted in Workflow Session context.
• Existing Unix behavior and protocol compatibility unless an explicit negotiated capability change is required.
• No generic terminal, PTY, shell-plugin, transport-plugin, or cross-platform compatibility framework merely to implement parity.

Acceptance

• A Windows Runner can advertise and execute a local persistent shell with the same model-facing lifecycle semantics as the Unix capability, with platform-appropriate shell dialect semantics.
• A Windows Runner can advertise named SSH resources and use them for run_shell and run_job while preserving binding/fencing and uncertainty semantics.
• A Windows Runner can open, execute, inspect, and close a persistent shell over a named SSH resource, or the issue is deliberately split before that stage with the earlier stages independently usable.
• Focused Windows tests cover state preservation, output bounds, timeout/reset behavior, cleanup, SSH resource generation changes, and uncertain remote delivery.
• Linux/macOS regressions remain covered by the existing persistent-shell/SSH suites.
• Update the stale Session documentation so it states the actual platform capability matrix instead of globally claiming that SSH persistent shells do not exist.