Container SSH: pin host keys, don't fall back to TOFU

When an app uses GIT_SSH_COMMAND with StrictHostKeyChecking=accept-new, it works on first run because the host key gets auto-trusted and stashed. The moment someone (rightly) tightens that to StrictHostKeyChecking=yes for security, every existing container deployment breaks with Host key verification failed because the container has no known_hosts at all — TOFU was hiding the gap. The instinct is to roll back to accept-new. Don't. The proper fix: pre-populate a known_hosts file with the remote's actual keys (ssh-keyscan -t ed25519,ecdsa,rsa github.com > known_hosts), cross-check the fingerprints against the platform's published values (GitHub publishes theirs at docs.github.com → SSH key fingerprints — match all three of ED25519/RSA/ECDSA), then point your SSH config or GIT_SSH_COMMAND at it via -o UserKnownHostsFile=/path/to/known_hosts. For containerized deployments, the file lives on a bind mount (alongside the SSH private key) so the runtime container reads both from the same place. After GitHub rotated their RSA key in 2023 — same ssh-keyscan + verify cycle refreshes it. The pinning is what makes the strict-checking actually secure; TOFU just defers the security problem to the first network adversary.