Q:

I2C Issues - SCL is stuck high

I am working on a custom carrier board using a TI microcontroller as the master and an ADC IC as the slave. It appears that sometimes SCL will stay high when it shouldn't, almost like the master releases it. We only get this fault condition on a reset of the MCU (or total system power cycle) but it does not happen every time, maybe one out of ten on average. 
Data transfer will be fine most of the time, until one of the unlucky resets causes the issues. You can see in the image below that after the address byte is sent SCL just goes high after a few clock pulses. Any ideas? 

A:

From recent comments:

the microprocessor does return an arbitration lost flag

Thanks, that is vital new info and deserves to be added to the question. So does this info:

I discovered this problem happens when the reset is pressed during activity on SDA. If the reset is pressed while SDA is high, the bus does not get messed up.

Based on the new info, I believe your problem is a duplicate of previous question "I2C bus occupied".
Your expectation that "I would think the MCU would come back up in a known good state with I2C initialized" is not true, because the MCU does not control the state of all devices on the I2C bus. The I2C Master only knows and controls its own state. It relies on other devices following the I2C protocol, to infer their state. Resetting only some devices on the bus can result in a mismatch between the internal states of the various devices on the bus, and lead to problems like yours.
When they restart, I2C Masters can be affected when they see that an I2C Slave is pulling SDA low, waiting for clock pulses from the I2C Master (which the Master won't send, as it was just reset) so the Slave waits, still pulling SDA low.
For example: After restarting, some I2C Masters (e.g. MCU), before they start the I2C SCL clock, will check the SDA signal. In your case, it sees that SDA is already low. This state can be interpreted as there being another I2C Master device driving the bus. Actually the cause of SDA being low is the I2C Slave, which was in mid-transmission before the MCU was reset. However now the Slave isn't receiving SCL pulses from the I2C Master and so it cannot complete its transmission. Most I2C Slaves don't timeout and release SDA in that situation, although a few do.
The fixes in the answer to the above linked question would apply here e.g. pulsing SCL manually, until the I2C Slave releases SDA, or resetting the I2C Slave (via a reset pin or local power switch to the I2C Slave(s)). Then restart I2C on the Master. The I2C master will see that SDA is no longer being held low, and so it will start to drive SCL again, as it won't be confused that there is another I2C Master on the bus.

