feat: apply address family preference to jump hops beyond the first

[inureyes]

Follow-up from the review of #247 (which implements #246).

Problem / Background

PR #247 wired -4/-6 and the ssh_config AddressFamily keyword through the primary connect path and the first jump hop. Hops 2 and later were declared out of scope at the time.

The rationale recorded for that decision was that the remote server resolves those addresses, so bssh cannot influence the family. That rationale is factually wrong, and PR #247's documentation is being corrected accordingly.

What actually happens: src/jump/chain/tunnel.rs (around lines 99 and 236) calls open_direct_tcpip_channel, which resolves the target locally and sends a literal IP string in the direct-tcpip request (src/ssh/tokio_client/channel_manager.rs around lines 214 to 222). bssh therefore does pick the address family for hop 2 onward, and for the destination reached through a chain. It simply does not apply the user's constraint at those call sites yet, so a -6 invocation can silently tunnel to an IPv4 address for every hop after the first.

Proposed Solution

Use the same mechanism already approved and implemented for -L forwarding targets in PR #247: pass the resolved AddressFamily into open_direct_tcpip_channel_with_family instead of calling the family-agnostic open_direct_tcpip_channel.

Scope:

1. Thread the resolved AddressFamily to the tunnel.rs call sites so it applies to jump hops 2 and later, and to the final destination reached through a chain.
2. Update docs/man/bssh.1 and ARCHITECTURE.md to drop the "not yet filtered" caveat once the filter is in place.

Acceptance Criteria

• src/jump/chain/tunnel.rs uses open_direct_tcpip_channel_with_family with the resolved family for hop 2 and later, and for the chained destination.
• The change is integrated into the real jump-chain code path, not added as a helper that no caller uses.
• A test asserts the address family of the address sent in the direct-tcpip request for a multi-hop chain, covering both -4 and -6.
• AddressFamily::Any behavior is unchanged (no regression for users who set no preference).
• docs/man/bssh.1 and ARCHITECTURE.md no longer claim that hops beyond the first are unfiltered.

Technical Considerations

The family-aware variant already exists and is used by src/forwarding/local.rs and src/forwarding/dynamic/socks.rs, so no new plumbing in channel_manager.rs is expected. The open question is where the resolved family should be carried from: SshConnectionConfig already travels into JumpHostChain, which makes it the natural source, but see the per-node resolution issue filed alongside this one for the caveat that this value is currently resolved once per dispatch rather than per host.