My wild guess at the moment is that it has to do with timing.
From what I've seen it seems to be that to actually really draw the image the firmware writes the buffer address and some other info to special addresses. I guess this signals a special chip to do the drawing using the new info. If this is the case, the drawing happens in parallel with whatever the firmware/CHDK/SDM is doing.
Perhaps that this camera, in contrast to others, only draws the image once when it is explicitly updated instead of every x ms? And contrary to the display the video output is updated late enough that you have time to change the buffer?
One part of your video that supports these ideas is the moment you first switch to playback mode in the second video (0:53). There the top of the image is still normal while the rest is flipped. As if the memcpy of your invert function (or perhaps as cache write?) catched up with the drawing.
I would experiment with this. Delay inverting the image. Increase a number every time invert is called and constantly draw it to the buffer (or just draw a "blinking" block). Etc.
The border at the left is possibly due to the buffer being wider than the image (i.e. every row is padded with some extra bytes). It's still odd, because when it has part of the original image, it suggest the padding is made of transparent pixels (or at least some YUV combo is interpreted as transparent). The flipped image does seem cropped at the right.
