I2C driver is issuing bus resets in the middle of perfectly reasonable transactions.

This is another follow-on to #1821. I'll repost the first trace from that issue for reference:

In this trace, we make it one I2C frame into a read transaction against the device at 0x6A (which happens to be an NVMe-MI interface, but I don't think that's material), when suddenly we take over the bus pins and do the bus recovery wiggle sequence, normally reserved for emergencies where SCL is stuck.

In this case, SCL is being held low by the disk for the first ~900us. This is within its rights. The problem is us -- immediately after the ack of its address, we're freaking out about it and triggering a bus reset, which is causing other knock-on problems (see #1821 and #1822).

I currently can't explain why we're doing this. I think fixing #1821 and #1822 will at least remove one layer of obfuscation and may reveal the source, but someone more familiar with the driver architecture might want to have a look.