Support SSH proxying for providers without SSH key listing

[coopernetes]

Summary

A generic provider (type: generic) can be pushed to over HTTPS but not over SSH. GenericProxyProvider already
accepts an sshUri, so the transport is wired; the block is that CheckUserPushPermissionHook fails closed for any
provider that is not an SshKeyFingerprintLookup, and tells the developer to use HTTP/HTTPS instead.

Bitbucket is in the same position for the same reason.

What is wanted

SSH proxying for providers that cannot list a user's SSH keys. The rest of the pipeline — URL rules, validation,
approval, audit — does not depend on fingerprint lookup and should apply over SSH exactly as it does over HTTPS.

Fingerprint-based verification genuinely cannot work against a host with no key-listing API, so that check is out of
scope here. Today an SSH key already imported into fogwall does satisfy the gate, so the shape of the fix is deciding
what a provider without key listing is allowed to fall back on, and making that an explicit operator choice rather than
an unconditional refusal.

Notes

• Applies to type: generic and Bitbucket.
• The current refusal is not silent — it blocks with "Provider does not support SSH key fingerprint lookup. Use
  HTTP/HTTPS transport to push to this provider." Whatever replaces it should stay as clear.
• The provider table in README.md lists SSH support per provider and will need updating.