Fix --timeout 0 being ignored instead of treated as unlimited

[inureyes]

Problem / Background

The --timeout 0 CLI option is intended to mean "unlimited/no timeout" as documented in the help text, but commands still timeout after 5 minutes (300 seconds) when this option is used.

Expected Behavior: When user explicitly passes --timeout 0, the command should run without any timeout limit (unlimited).

Actual Behavior: Command times out after 5 minutes regardless of --timeout 0.

Root Cause Analysis

In src/app/dispatcher.rs (around lines 350-355), the timeout resolution logic treats 0 as "not specified":

// Current buggy code
let timeout = if cli.timeout > 0 {
    Some(cli.timeout)
} else {
    ctx.config.get_timeout(...)  // Returns None if not configured
};

When cli.timeout == 0, the code falls back to the config lookup. If the config has no timeout set, None is returned. Then in the SSH client/command execution layer, None triggers the default 300-second (5 minute) timeout.

The help text explicitly states "(0 for unlimited)" but this never works because 0 is indistinguishable from "no value provided."

Proposed Solution

1. Change CLI field type: In src/cli/bssh.rs, change timeout: u64 to timeout: Option<u64> with no default value
2. Update timeout resolution logic: In src/app/dispatcher.rs:
   • If user explicitly specified --timeout (i.e., cli.timeout.is_some()), use that value directly including 0
   • Only fall back to config timeout when user did not specify --timeout at all
3. Pass explicit zero: When user specifies --timeout 0, pass Some(0) to the executor to signal unlimited timeout

Acceptance Criteria

• bssh -c cluster --timeout 0 "long-running-command" runs without timeout
• bssh -c cluster "command" (no --timeout flag) uses config timeout or default 300s
• bssh -c cluster --timeout 60 "command" uses 60-second timeout
• Help text remains accurate: "(0 for unlimited)"
• Unit tests cover the timeout resolution logic

Files to Modify

• src/cli/bssh.rs - Change timeout field to Option<u64>
• src/app/dispatcher.rs - Update timeout resolution logic to distinguish "not specified" from "explicitly set to 0"
• Potentially src/ssh/client/command.rs or executor - Ensure Some(0) is handled as unlimited

Additional Context

This is a usability bug that affects users running long-running commands like large file transfers, database migrations, or batch processing jobs across cluster nodes.

[inureyes]

b22d792

[inureyes]

Fixed in commits b22d792 and 4d43690.

Summary of Changes

The --timeout 0 flag now correctly works as unlimited timeout instead of being ignored.

Root Cause

The CLI timeout field was u64 with a default value of 300, making it impossible to distinguish between "user didn't specify" and "user explicitly set to 0".

Fix

1. Changed timeout: u64 to timeout: Option<u64> in CLI definition
2. Updated dispatcher logic to pass through Some(0) when user explicitly specifies --timeout 0
3. The SSH client already handled Some(0) as unlimited

Behavior After Fix

• bssh --timeout 0 ... → Runs with no timeout (unlimited)
• bssh --timeout 60 ... → Uses 60-second timeout
• bssh ... (no --timeout) → Falls back to config or 300s default

All acceptance criteria are met.