fix(ssh): generate a host key ssh2 can actually parse; self-heal the bad one #5516

Why SSH didn't come up with #5509

The enablement deploy surfaced a dormant Block-SSH-1 bug: [ssh] failed to start: Cannot parse privateKey: Unsupported key format. Node emits ed25519 keys only as PKCS#8/OpenSSL PEM — formats the ssh2 library cannot parse — so the ephemeral-generation path never worked; SSH_PORT=0 hid it since launch. Worse, #5509's persistence saved that unusable key to the volume, where a PEM-shaped sniff (includes("PRIVATE KEY")) would reload it forever.

• Generated keys are now classic RSA-3072 PKCS#1 PEM — a format ssh2 parses. (Want ed25519? ssh-keygen emits OpenSSH format, which ssh2 also parses — set SSH_HOST_KEY.)
• Validation is by ssh2's own parser, not a substring sniff: a persisted key ssh2 rejects — including the exact PKCS#8 file the outage-day deploy left at /data/repos/.gluecron/ssh_host_ed25519_key — regenerates in place. The box self-heals on deploy, no manual cleanup.
• An operator-supplied SSH_HOST_KEY is still used as given (failing loudly beats silently substituting a host identity), but the unparseable case now names itself at load time instead of dying as a generic startup error.

Tests: 27/27 including two new — the generated key must satisfy ssh2.utils.parseKey (the outage class, pinned), and a persisted legacy PKCS#8 key is regenerated. Typecheck clean.

🤖 Generated with Claude Code