We probably want the entire I2C driver to wait for the sequencer to finish setting things up

Currently, certain I2C clients will check power state before issuing certain I2C requests. However, I think we might want to interlock the entire I2C driver's startup on the sequencer reaching some basic level of initialization.

Thinking about the out-of-band reset lines we've added in Gimlet D (yaaaaaay), if we add code to the I2C driver to pulse all the resets early in startup, we could pretty easily wind up with this interleaving of events if the SP gets reset while the host is up:

1. Sequencer starts doing things
2. I2C driver starts doing things like pulling resets
3. I2C driver has reset all muxes and starts accepting bus traffic
4. Sequencer pulls CRESETB, dropping power state to A2.
5. Muxes may now be left connected to unpowered domains.

I think our safeguards in tasks like thermal would prevent this from happening, and I could imagine inserting code in the I2C driver to try to recover from certain cases by resetting muxes again, but I feel like it'd be easier to reason about if we just had the I2C driver wait until the sequencer has made the power state consistent.

Start by tracing the I2C driver's startup path and the sequencer initialization and power-state handling described in the issue. Confirm the ordering around reset and bus availability, then define completion as the I2C driver remaining blocked until the sequencer has established a consistent power state; the payload names no specific files or tests.