SSH fleets reject same host on different SSH ports

[peterschmidt85]

Summary

SSH fleets currently reject a new fleet if an active SSH fleet already uses the same hostname/IP, even when the two fleets use different SSH ports. This blocks valid setups where multiple machines are exposed through the same public address via port forwarding/NAT.

This is not accelerator-specific; it showed up while creating separate SSH fleets for two different hosts behind the same public IP but on different SSH ports.

Steps to reproduce

Create and apply one SSH fleet:

type: fleet
name: ssh-a

ssh_config:
  user: user
  port: 32101
  identity_file: ~/.ssh/id_rsa
  hosts:
    - 203.0.113.10

dstack apply -f ssh-a.dstack.yml -y

Then create and apply another SSH fleet with the same hostname/IP but a different SSH port:

type: fleet
name: ssh-b

ssh_config:
  user: user
  port: 32001
  identity_file: ~/.ssh/id_rsa
  hosts:
    - 203.0.113.10

dstack apply -f ssh-b.dstack.yml -y

Actual behavior

The second apply fails with:

Instances [203.0.113.10] are already assigned to a fleet.

Expected behavior

203.0.113.10:32101 and 203.0.113.10:32001 should be treated as different SSH endpoints and should be allowed in separate fleets.

The same effective endpoint should still be rejected, e.g. two active fleets both using 203.0.113.10:32101.

Fix direction

The duplicate-host validation should use the effective SSH endpoint instead of only the hostname/IP. The error message should also include enough endpoint information to make the conflict clear.