Give each Reflash board its own persistent SSH host key

[eliasbakken]

Summary

mkimage.sh installed openssh-server during the image build, which generates SSH host keys as a side effect - baked into that one build, they'd be identical across every image and every board flashed from it (#80). That's a real MITM/impersonation risk: the private key extracted from any single image works against every other board running the same build.

Deleted the build-time keys and added ssh-keygen-boot.service, which restores (or generates once and saves) them against /mnt/usb instead - the one thing that actually persists across reboots on this board, since the root fs runs from initrd and doesn't. Ordered before both ssh.service and reflash.service so it has /mnt/usb to itself first - mount-unmount-usb has no locking of its own, so overlapping access from two processes isn't safe.

On a freshly-flashed drive, /mnt/usb's second partition doesn't exist yet - it's normally created by expand-usb, called from the Go server's own startup, which runs after this unit specifically so it doesn't race the server for the drive. ssh-keygen-boot calls expand-usb itself first; it's idempotent, so the Go server calling it again moments later is harmless.

Testing

• make test-bats / go test ./... - no regressions (this script's logic depends on real block-device/mount behavior that isn't meaningfully unit-testable the way the other bats-covered scripts are, so validation is live-hardware only, below).
• Live-tested on real hardware through the actual boot sequence, not just invoked directly:
  • Flashed a fresh image, confirmed on first boot that ssh-keygen-boot.service correctly detects no /mnt/usb partition yet, creates it via expand-usb, generates keys, and saves them to /mnt/usb/ssh_host_keys/.
  • Rebooted, confirmed the exact same key (verified by SHA256 fingerprint) is restored from USB rather than regenerated.

Closes #80