## Summary - Retry the fallback keyserver (`hkp://keyserver.ubuntu.com:80`) when gpg fails with `gpg: keyserver receive failed: Server indicated a failure` (GPG error 219), not only on timeout / "Network is unreachable". - Stop mapping that error to "unable to establish connection to key server ...": gpg reports it *before* any keyserver connection is attempted, so the old message was misleading (it reads as a connectivity problem and sends debugging down the wrong path). ## Root cause observed in the wild A snapcraft build fetching a repository key failed wholesale with `unable to establish connection to key server 'keyserver.ubuntu.com'`. The real gpg error was "Server indicated a failure". Investigation showed: - The keyserver itself was healthy (`hkp://…:80`, `:11371` and `hkps://…:443` all serve the key fine). - gpg/dirmngr performs an **optional SRV lookup** (`_pgpkey-http._tcp.keyserver.ubuntu.com`) when the keyserver URL has no explicit port. Some resolver setups answer SERVFAIL instead of NXDOMAIN for names without records; dirmngr maps that to GPG error 219 ("Server indicated a failure") and aborts before connecting to the keyserver. - The failure is transient in practice (resolver/keyserver blips), so a retry with the fallback keyserver — which carries an explicit port and thus skips the problematic path — recovers cleanly. This also matches how craft-archives already treats timeout/unreachable as retry-worthy. ## Testing - Extended `test_install_key_from_keyserver_with_gpg_errors` to cover all retryable messages (incl. "Server indicated a failure") asserting the fallback call with the proxy keyserver option. - New test: "Server indicated a failure" from a **non-default** keyserver must *not* be retried (one gpg call) and surfaces the improved message. - New test: both default and fallback failing surfaces the error after exactly two calls. `uv run pytest tests/unit` (229 passed), `ruff check`, `ruff format`, `codespell` clean.