fix(installer): stamp host SSH keys with the target hostname

[RISK-alt]

The bug

Installed machines end up with their host SSH keys commented root@m instead of carrying their own hostname.

Root cause

Host keys are generated at install time by ssh-keygen -A, run through nixos-enter (ageKeysProvisionScript in lib/default.nix). nixos-enter chroots into /mnt but keeps the installer's UTS namespace, and ssh-keygen takes the key comment from the hostname of the running system — the installer, not the machine being installed.

buildUSBInstaller overrides that hostname to m${inventoryId} (lib/default.nix:391). In Nix toString null is the empty string, so on a machine whose inventoryId is unset the installer's hostname is literally m — hence root@m.

Confirmed experimentally: ssh-keygen -A reads the hostname from the UTS namespace, and forcing it with unshare -u changes the comment accordingly.

The fix

Rewrite the comments after generation with ssh-keygen -c, using the hostname the target system actually boots with. ssh-keygen -c updates the comment in both the private key file and its .pub.

Testing

• Bug reproduced and fix verified against a realistic fixture. In a mount + UTS namespace, with a tmpfs on /mnt and the hostname forced to m, ssh-keygen -A produces root@m on every key type — the exact symptom reported. Running the lines this change emits, extracted verbatim from the generated autoinstall-terminal script, then rewrites every key to root@<target hostname>, in the private keys and the .pub files alike.
• Generated script inspected. A buildInstallerSystem instantiated with ageHostKeys = true emits the loop with the target hostname correctly interpolated.
• nix-build -A tests passes, all four tests, including idempotent-autoinstall — which exercises buildInstallerSystem, the function this PR changes.
• nixfmt -sc, statix check --config statix.toml and reuse --root . lint all pass.

Not covered: a real install on physical hardware. Key generation itself is untouched; the change only rewrites comments afterwards.

Out of scope

The TPM2-backed keys produced by ssh-tpm-keygen -A most likely carry the same wrong comment, but ssh-keygen -c cannot rewrite a key sealed in the TPM. Happy to follow up if you want those consistent too — it would need a different mechanism, so I left it out rather than guess.

Closes #115

[rlahfa-dinum]

Looks reasonable to me.