fix(restore-check): share restore preconditions and report unavailable inputs (#636)

restore-check now runs restore's own pre-restore validation instead of reporting green for a rig that restore would refuse. The validator moves unchanged into a shared module; restore keeps calling it at the same point with the same messages, order and refusals. restore-check runs it once per rig on the snapshot that rig up --existing would choose: refusals show red, warnings alone show yellow, and an empty result is green, bounded to what was checked. It never captures or invents a snapshot.

When there is no usable current-occupant snapshot, restore-check reuses ordinary up's existing current-state rehydrate eligibility: an eligible stopped or partial rig keeps its down or partial status and the rig up --existing suggestion, with the restore inputs shown yellow as not inspected; an ineligible rig shows up's own blockers in red; a missing rig or a read error stays a named unknown for that rig only. In the overall verdict a known red now wins over an unrelated unknown (exit 1 before exit 2), while each rig's own status and the counts remain visible.

Composed rig status skips the added validation for rigs whose seats are all running and ready; explicit restore-check always runs it. Query counts per assessed rig are documented in the PR; the full snapshot history is still read for stopped rigs, which is follow-up work. P2 spec-root corrections and launch-record rig_id are out of scope.

Refs #130