[BUG] apm install fails validation for SSH-accessible generic Git hosts (non-GitHub/non-ADO)

[zzoubian]

Describe the bug
apm install fails the pre-install validation step when targeting a self-hosted Git server (e.g., a GitLab instance) that is accessible via SSH but not via unauthenticated HTTPS. The validation probes the repository with git ls-remote over HTTPS only, receives a 401/fatal prompt-disabled error, and rejects the package — even though the subsequent clone would succeed over SSH using the user's configured SSH keys.

To Reproduce

1. Have a repository hosted on a self-hosted Git server (e.g., git.example.org) accessible via SSH keys but not unauthenticated HTTPS.
2. Run:
   apm install git@git.example.org:org/group/repo.git
3. See error...
   [*] Validating 1 package...
   Trying git ls-remote for git.example.org
   git ls-remote rc=128: fatal: could not read Username for 'https://git.example.org': terminal prompts disabled
   [x] git@git.example.org:org/group/repo.git -- not accessible or doesn't exist
   All packages failed validation. Nothing to install.

Expected behavior
Validation succeeds and the package is installed. APM should try SSH (git ls-remote git@host:path.git) before falling back to HTTPS for generic (non-GitHub, non-ADO) hosts — the same transport preference already used in the clone step (_clone_with_fallback).

Root cause

In install.py, the _package_exists_and_accessible function always calls git ls-remote with an HTTPS URL for generic hosts, even though no token is available and HTTPS may require credentials. The actual clone path (_clone_with_fallback) already tries SSH first for generic hosts, creating an inconsistency between validation and installation.

Suggested Fix

# For generic hosts, try SSH first (no credentials needed when SSH
# keys are configured) before falling back to HTTPS.
urls_to_try = []
if is_generic:
    ssh_url = ado_downloader._build_repo_url(
        dep_ref.repo_url, use_ssh=True, dep_ref=dep_ref
    )
    urls_to_try = [ssh_url, package_url]   # package_url is the HTTPS fallback
else:
    urls_to_try = [package_url]

result = None
for probe_url in urls_to_try:
    result = subprocess.run(
        ["git", "ls-remote", "--heads", "--exit-code", probe_url],
        capture_output=True, text=True, timeout=30, env=validate_env,
    )
    if result.returncode == 0:
        break

Additional context
The regression window is narrow: the bug only surfaces when all three of the following are true:

The host is not github.com or dev.azure.com (generic host path)
No APM-managed token is configured for the host (GITHUB_APM_PAT / ADO_APM_PAT are absent)
The repository is accessible via SSH but requires credentials over HTTPS

[sergio-sisternes-epam]

Thanks for the detailed report and root-cause analysis, @zzoubian.

Confirmed as a bug. The core problem is that _package_exists_and_accessible only probes via HTTPS, while _clone_with_fallback already tries SSH first for generic hosts -- so validation rejects repos that would clone successfully.

This sits within a cluster of related SSH/HTTPS transport issues we're tracking:

• [BUG] Corporate networks blocking port 22 cause SSH clone attempt to hang #652 (accepted, PR Enable SSH timeout to fallback to HTTP. #653) -- the inverse problem: corporate firewalls silently drop SSH (port 22), and the SSH clone attempt hangs with no timeout before the HTTPS fallback is reached.
• [BUG] Ignores ssh://, tries https (Bitbucket Datacenter) #661 (accepted, PR fix: preserve ssh:// dependency URLs for Bitbucket Datacenter repositories #665) -- explicit ssh:// URLs in apm.yml are ignored; APM rewrites them to HTTPS, breaking Bitbucket Datacenter with custom SSH ports.
• [FEATURE] Support installation from git repositories hosted over HTTP only #636 (needs-triage) -- HTTP-only corporate git servers rejected by validation, which only recognizes HTTPS and SSH.

The fix for this issue should align the validation probe order with the clone fallback chain, and coordinate with #652/#653 to ensure both paths use consistent transport selection and timeouts.

Accepting this as a confirmed bug. Contributors welcome -- the scope is _package_exists_and_accessible in install.py.