fix: ssh-proxy child process loses cluster name, defaults TLS path to 'navigator' #49

Bug Description

When running nav sandbox create --keep --forward <port>, the SSH proxy child process fails to find TLS certificates because it resolves the wrong cluster directory path.

Error:

Error: × failed to read TLS CA from /home/nvidia/.config/navigator/clusters/navigator/mtls/ca.crt
╰─▶ No such file or directory (os error 2)
Error: × ssh exited with status exit status: 255

Root Cause

The ssh_session_config() function in ssh.rs constructs a ProxyCommand for the child nav ssh-proxy process using token mode (--gateway, --sandbox-id, --token) but does not pass the --cluster flag. The child process therefore has no cluster_name in its TlsOptions, and the TLS directory resolution in default_tls_dir() falls back to the hardcoded "navigator" for any 127.0.0.1 gateway URL.

Call chain:

1. Parent process correctly resolves cluster name (e.g., "navigator-main") and sets tls.cluster_name
2. ProxyCommand is built without --cluster: nav ssh-proxy --gateway <url> --sandbox-id <id> --token <tok>
3. Child process creates fresh TlsOptions with cluster_name: None
4. default_tls_dir() sees 127.0.0.1 host and falls back to "navigator"
5. TLS cert path resolves to ~/.config/navigator/clusters/navigator/mtls/ instead of ~/.config/navigator/clusters/navigator-main/mtls/

Steps to Reproduce

1. Clone the repo into a directory not named navigator (e.g., navigator-main)
2. Run mise run cluster (creates cluster named after directory)
3. Run nav sandbox create --keep --forward 18789
4. Observe the TLS CA error referencing the wrong cluster name

Expected Behavior

The child ssh-proxy process should use the same cluster name as the parent, resolving TLS certs from the correct directory.

Proposed Fix

1. Add a cluster_name() getter to TlsOptions
2. Include --cluster <name> in the ProxyCommand when a cluster name is available
3. Apply the cluster flag in the token-mode match arm of ssh-proxy