Restrict ssh-keyscan to -t rsa to avoid tripping rate limiting

Latest diagnostic run showed aquaria's OpenSSH responding fine on the
first of several near-simultaneous connections ssh-keyscan opens (one
per default-probed key type), then hanging on the rest with no
response — a rate-limiting signature, not an outright ban. Both hosts
confirmed to offer an RSA host key, so scan just that type: one
connection per host instead of ~4 at once. Left the diagnostic step in
to confirm before removing it. Dropped -v now that the cause is known.

.gitea/workflows/build-deploy.yml

@@ -46,8 +46,12 @@ jobs:
           mkdir -p ~/.ssh
           printf '%s\n' "$DEPLOY_SSH_KEY" > ~/.ssh/deploy_key
           chmod 600 ~/.ssh/deploy_key
-          ssh-keyscan -4 -v -H git.haemka.in >> ~/.ssh/known_hosts
+          # -t rsa: both hosts confirmed to offer an RSA host key. Restricting
-          ssh-keyscan -4 -v -H -p "${DEPLOY_PORT:-22}" "$DEPLOY_HOST" >> ~/.ssh/known_hosts
+          # to one type means one connection per host instead of ~4 fired at
+          # once (one per probed key type), which aquaria's connection-rate
+          # limiting was intermittently dropping past the first.
+          ssh-keyscan -4 -t rsa -H git.haemka.in >> ~/.ssh/known_hosts
+          ssh-keyscan -4 -t rsa -H -p "${DEPLOY_PORT:-22}" "$DEPLOY_HOST" >> ~/.ssh/known_hosts
 
       - name: Fetch theme submodule
         run: |