I believe the issue is that TF, actually the underlying VBulletin software, is ignoring the Orientation info that accompanies most images. There is the orientation of the stored JPEG (to use that as an example), but also orientation info to tell the displaying software how to rotate it, if at all.
IPhones always record the JPEG in landscape orientation, button right, lens left. It then adds the orientation info based on how you are holding the camera at the time.
Display software is supposed to load the JPEG, the rotate it according to the Orientation info. This is why most programs display the image correctly, yet others do not.
When you view an image that either appears correctly in the first place because the program has rotated it as instructed, or because it was displayed in its underlying JPEG orientation and you manually rotated it, and then you save it, I think most programs save the new JPEG as viewed and rest the Orientation info to indicate no rotation is required. Now if software like TF display it and ignore the Orientation info, it still displays correctly because no orientation rotation is required. This is how the photos get “fixed”.
Unlike a iPhone, it would appear that photos are stored as JPEGs after they have been rotated, so never include Orientation info indication that rotation is required.
So, I would argue that the problem is in TF because it doesn’t display images as instructed by the image. Androids don’t expose the problem, but that doesn’t make TF right.