Expose a VM's SSH host keys in the customer API

[v0l]

Closes #154.

ApiVmStatus gains host_ssh_keys: [{ key_type, public_key, fingerprint_sha256 }] — empty until captured, so a client can verify the host on first connect instead of accept-new. Kieran's call on the issue: scanned with ssh-keyscan from the Proxmox node, public keys only, nothing runs in the guest.

• Capture hangs off the periodic VM check, next to the DNS reconcile (lnvps_api/src/worker.rs:917): the keys do not exist until cloud-init has made them and sshd is up, and a VM that has none self-heals. VMs that already have keys skip immediately; a guest that never answers is retried at most hourly (HOST_KEY_SCAN_RETRY_SECS).
• Reinstall clears them (worker.rs:2560) — the guest regenerates its keys, so the stored ones belong to an image that is gone.
• Stored as the raw scan in vm.ssh_host_keys rather than a table: the set is written and read whole and never queried by key. It has its own DB method (lnvps_db/src/lib.rs:423) and is deliberately not part of update_vm, so a caller holding a VM loaded before the capture cannot wipe it.
• Parsing and fingerprinting are a pure function with tests (lnvps_api_common/src/ssh_host_key.rs); anything not a well-formed line of a known algorithm, or whose blob disagrees with its stated type, is dropped rather than handed to a client to pin. Fingerprints are pinned in the tests against ssh-keygen -lf output for the same key.
• Tests: parser unit tests, a mock-DB test that the field reaches vm_to_status parsed, and an e2e assertion that it is an empty array before capture and the parsed key afterwards.

The scan itself has no test — it needs a Proxmox node and a booted guest. It uses the same connect_with_key + execute pattern as the host-info collector (worker.rs:1441).

Originating channel: Buzz #721a8a6c-c36c-5fa1-ae07-822ddc8567c5