fix(cua-driver): report inaccessible Windows daemon pipes

[injaneity]

summary

• require a successful daemon protocol request before cua-driver status reports that the daemon is running
• distinguish an existing but unreachable endpoint and explain the Windows same-account named-pipe boundary
• document that OpenSSH and the interactive daemon must use the same Windows SID
• remove the unsupported session field from the documented status output

closes #2771

root cause

The Windows daemon pipe is intentionally private to the SID that owns the interactive daemon. WaitNamedPipeW, which backed the first status check, proves that the pipe name exists without proving that the caller may open it. A different SSH account therefore saw “daemon is running” from status, then received Windows error 5 when MCP attempted the real connection.

Session 0 is not the blocker. A same-SID Session 0 client can connect to the interactive Session 1 daemon.

validation

Exact head: bbebabcd5

Live Windows OpenSSH replay against an elevated interactive Cua daemon:

• interactive daemon: Session 1, SID suffix -1000
• different-user SSH client: Session 0, SID suffix -1001
  • status detected the pipe
  • mcp --socket \.\pipe\cua-driver failed with Access is denied. (os error 5)
• same-user SSH client: Session 0, SID suffix -1000
  • the same MCP command accepted initialize and returned the Cua server response

The temporary SSH key, test binary, account allowance, and ACL changes were removed after the replay; the original OpenSSH configuration was restored.

Also checked:

• git diff --check
• source assertion that status performs send_request before printing “daemon is running”

Focused Rust tests were not run locally because Cargo is unavailable in this Windows workspace; pull request CI is pending.