fix(prelaunch): v0.0.19 - correct SSH key count and log key fingerprints

[Leechael]

Why

A CVM booting with one injected key logged:

Set root authorized_keys from user preferences, total 0 keys

The key was written and SSH worked — the count was wrong. It came from wc -l, which counts newlines, while jq -j writes the value with no trailing newline, so a one-key file counted as zero.

The same missing newline carried two more consequences: a later append concatenates onto the previous line and silently corrupts authorized_keys, and the wc -l > 1 guard kept the dedup pass from running for a two-key file.

What changed in v0.0.19

• jq -r instead of jq -j, so the value is newline-terminated.
• Dedup runs unconditionally, which also drops the blank line an empty key list leaves behind.
• Counting uses a pattern that does not depend on the final newline.
• Every authorized key's SHA256 fingerprint is logged, in the format ssh-keygen -lf and GitHub use, so a boot log can be matched against the account's key list without shelling into the CVM.

Set root authorized_keys from user preferences, total 2 keys
  ssh-ed25519 SHA256:6OKoIHh0+L2URA+iptwZ1EF3NlwXZ6o0BW9/bnoR7ds
  ssh-rsa SHA256:LxIr2ZUyQLBZtTcELwmpjnhrYTYL/4ZUhXb2ngIo0RU

Both values are byte-identical to ssh-keygen -lf on the same keys.

Guest image constraints

The guest image has neither ssh-keygen nor a base64 applet — every dstack 0.5.x image builds BusyBox 1.36.1 from the same pinned kirkstone defconfig, which ships base32 only. So openssl performs both the decode and the digest, guarded by a command -v check. openssl is present in every 0.5.x image via ca-certificates, the same dependency v0.0.18 already relies on for openssl passwd -6.

openssl base64 -d exits 0 on undecodable input and emits nothing, which would print the SHA256 of the empty string as a real fingerprint. The decoded byte count is checked first, and such a line prints <unreadable key> instead.

Reading the file uses while read ... || [[ -n "$key_type" ]] so a file with no final newline does not lose its last line — the same trailing-newline trap this release fixes.

Verification

Exercised locally against the committed file with real keys, covering repeat execution (idempotent — no duplicate or concatenated lines on a second boot), an empty key list, a file with no final newline, and an undecodable blob. bash -n clean.