Being able to power on a sled during a host flash update is probably bad

My leading explanation for the failure in #1613 is that, while wicket was doing an image update, some other program asked the sled to power itself on into A0. That may or may not be what actually happened, of course, but the fact is that nothing in the SP will currently prevent that.

I think we probably want an interlock here that rejects attempts to go into A0 while the host flash is muxed to the SP and being actively used for something like an update.

There's some design work that needs to happen here -- is the interlock automatic in response to the host flash mux, or is it requested? Are there cases where we want to mess with the host flash without the interlock, or should it always occur? etc.

Start by tracing the SP handling of the host flash mux and requests to power the sled into A0, using the suspected failure in #1613 as context. Define whether the interlock is automatic or requested, whether host-flash operations can bypass it, and what behavior should be considered complete.