want slot-specific context for failures to set the component active slot

While trying to set an active slot on a Cosmo I got the following error:

$ /usr/bin/faux-mgs --interface dut0 --discovery-addr [fe80::aa40:25ff:fe04:1501]:11111 component-active-slot host-boot-flash -s 0 --persist
Dec 31 14:37:34.015 INFO creating SP handle on interface dut0, component: faux-mgs
Dec 31 14:37:34.016 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1501%3]:11111, interface: dut0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: update currently unavailable (slot busy)

Ultimately, the error message is reasonable. The system is in a boot loop and therefore the host "owns" the SPI flash (though this concept makes less sense in terms of our eSPI implementation). However, while I eventually figured that out, the fact that the error was "slot busy" took me quite some time to go there. At first I thought maybe there was some pending update or something else going on and it took me a while to realize it was because we were in this boot loop, especially as several others succeeded. I realize this requires changes to the faux-mgs protocol, but a more specific error or message for specific slots would be helpful here. If this had been something about the slot being muxed away that would have made it much more obvious. I also assume that there are going to be other, slot-specific failure modes that will occur where additional information would be useful.

Start at the faux-mgs protocol path for the component-active-slot command and trace how the “slot busy” response is produced. Done means failures identify the affected slot and provide actionable context for cases such as a boot loop or a slot being muxed away.