fix(ssh): suppress cascading DNS error when sign mode fails

[brollb]

🚀 What

When SSHing into a training job that isn't in RUNNING state, users were seeing two error messages:

1. baseten-ssh: API error (400): Training job must be in RUNNING state ... ← the relevant one
2. ssh: Could not resolve hostname ...: nodename nor servname provided, or not known ← confusing noise

This PR removes the second spurious error.

💻 How

The SSH config uses a Match exec block that runs proxy-command.py --sign before the connection. SSH only applies the Match block (and thus ProxyCommand) if the exec command exits 0. Previously, any sign failure called error() → sys.exit(1), causing SSH to skip ProxyCommand and attempt direct DNS resolution of the *.ssh.baseten.co hostname — which fails with the confusing secondary error.

Fix:

• main_sign() now always exits 0. In sign mode, error() suppresses stderr output and saves the message to a per-hostname sign-error cache file (~/.ssh/baseten/.jwt-cache/<hostname>.sign-error).
• main_proxy() checks the cache at startup. If a sign error is present, it clears the file, prints the message, and exits 1 — so users see exactly one, actionable error message.

🔬 Testing

Manually verified the two-error scenario is reduced to one. Existing unit tests in truss/tests/cli/test_ssh.py all pass (43/43).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Brian Broll seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}