Adding a sled shouldn't require operators to go through the mupdate recovery workflow

When adding a sled to a rack, we first mupdate the sled to match the current target release. This means when we add the sled to the rack, Reconfigurator detects that a mupdate has occurred, which then requires the operator to go through the system_update_recovery_finish() Nexus endpoint (which is more typically used to recover from a full-system mupdate).

With some care, Reconfigurator should be able to detect "we've found a sled that has been mupdated to the current target release", and in that case, not bump the blueprint's min target release generation and therefore not require the operator to go through the update recovery process.

In the fullness of time, we've discussed Nexus driving the mupdate of a sled being added to the rack. This seems like a (necessary?) stepping stone to that world, and it would make the add sled process meaningfully smoother today.

Start by tracing Reconfigurator's sled-add path and how it detects a prior mupdate, then review the interaction with the system_update_recovery_finish() Nexus endpoint. The change is done when a sled mupdated to the current target release can be added without bumping the blueprint's minimum target release generation or requiring update recovery.