Restore uploaded with keep as its erase policy silently installs WITHOUT the restore

[VijitSingh97]

The battery's restore leg watched it happen end to end: upload the backup archive on the installer's combined page with wipe=keep (the natural disaster-recovery combo — config from the archive, synced chains kept), and the machine 'keep'-installs immediately, drops the archive, and powers off. The operator's backup never touches the disk.

Mechanism: the bare-keep reinstall shortcut fires on "install-request=keep + no staged config" — and it runs BEFORE the restore consume in the firstboot loop, so a staged restore-archive loses the race every time. Two sibling hazards with the same shape: a restore REJECTED for a typo'd passphrase, and a typed submission failing remote-node preflight, both leave the install-request staged — the next loop pass bare-keep-installs without the config the operator thought they submitted.

Fix (on fix/battery-green): the shortcut also requires no staged restore archive, and both rejection paths hand the install-request back with the form. Proven at tier 4 by the install phase's restore leg (restore+keep) beside the keep leg (bare keep).

[VijitSingh97]

Fixed by #975, merged into develop-v2 as fa02566 (closing keywords don't fire on non-default-branch merges). Verified by the full KVM battery + validation set on gouda: boot 5/0, update 15/0, install 42/0 (identity restore end-to-end), provision 30/0 (migration hold + journal assert), rig/fault green, media 8/0, reset 15/0. Bench deploy of the merged tip is in progress.