feat: add connection pooling infrastructure for future features

[inureyes]

Summary

This PR adds a connection pooling module as infrastructure for future features. After thorough analysis, connection pooling provides no benefit for bssh's current one-shot execution model, but the infrastructure is added for future interactive features.

Changes

• Add ConnectionPool module (src/ssh/pool.rs) as placeholder implementation
• Export pool module from src/ssh/mod.rs
• Document pooling design decision in ARCHITECTURE.md
• Include unit tests for the pool API

Analysis Results

Connection pooling is not beneficial for current usage because:

• Each CLI invocation executes exactly one operation per host then terminates
• No scenarios exist where connections would be reused within a single execution
• The async-ssh2-tokio Client type doesn't support cloning or connection reuse

When Pooling Would Help

The infrastructure will be useful when implementing:

• Interactive shell mode with persistent sessions
• Watch mode for periodic command execution
• HTTP API server mode
• Batch command execution from files
• Command pipelining on the same hosts

Implementation Details

• Pool is disabled by default (no performance overhead)
• Provides complete API surface for future activation
• Always creates new connections in current implementation
• Includes proper documentation explaining the limitations

Testing

• Added 3 unit tests verifying pool behavior
• All tests pass successfully
• No impact on existing functionality

Recommendation

Focus on more impactful optimizations like:

• Connection timeout tuning
• SSH compression for large outputs
• Buffered I/O optimizations
• Parallel DNS resolution