Add guardrails to catch clean-slate -> RSS after a live update

If a rack goes through this sequence:

• mupdate in the factory to release N
• RSS on release N
• perform a Nexus-driven update to release N+1
• support clean-slates the rack
• attempt to perform RSS

the rack will be in an invalid configuration: the live update will have updated all the hubris components and the OS images to release N+1, but the install dataset will still have the zones on it from release N. The rack will probably make it through RSS, since in general these are the components updated first in the update DAG, but the resulting control plane will look like it's partway through an upgrade from N to N+1. (If there had been multiple live updates, then all bets are off - RSS would be trying to run with hubris/OS components at release N+2 or higher against control plane zones from release N.)

In terms of procedure, we currently expect any rack going through RSS to have been mupdated to the release we're trying to set up. We should install some kind of guardrail to catch the above situation and refuse to perform RSS. (Version the files under the install dataset? Remove them as a part of the live update? Something else?)

Trace the RSS, mupdate, Nexus-driven live update, and install-dataset paths described in the issue to determine how release versions are recorded and compared. Define a guardrail that detects a clean-slate followed by RSS after a live update and refuses the operation; done means the invalid sequence is rejected before RSS proceeds, with coverage for multiple live updates.