Howdy! Before I mark this bug as resolved, I wanted to save the analysis I had to do here: it might be interesting to (a tiny fraction) of people impacted by this issue, and it’d be nice to be able to refer to it in the release notes.
Background
PhotoStructure uses heif-convert to convert HEIF/HEIC images to browser-accessible JPEGs.
I’d verified that heif-convert worked properly on Mac and Linux. Mac uses the built-in sips, and Linux boxen ship with heif-convert from the libheif-examples package.
I couldn’t reproduce this issue because I would always try examples on PhotoStructure for Desktop on macOS and Ubuntu, on PhotoStructure for Servers using Node, and it worked on my machine.
On Ubuntu 20.04, the version of heif-convert, v1.6, emits correctly oriented JPEGs: the source orientation is ignored, the converted image is never rotated, and because the Orientation metadata is retained, everything works.
Clues
I (finally!) noticed that the Alpine/docker version of heif-convert was a different version. (Could that be it?)
I discovered that version 1.9 and later emit rotated JPEGs (as opposed to the older versions, that ignore rotation). What’s incorrect is that they also copy the source EXIF metadata, unadjusted, to the destination JPEG. This results in the encoded image being correctly oriented, but due to the retained Orientation tag, the image is rotated, again, and boom, we have this bug.
Solutions
My initial thought was to only apply a bugfix to the buggy versions, but I can’t tell what version is installed because heif-convert doesn’t respond to --version and all versions link to /usr/lib/libheif.so.1 
.
I thought of adding heuristics to detect if the converted JPEG from HEIC had incorrect dimensions, but this doesn’t handle when people hold their phone “upside-down”, nor does it handle square originals (which is an Instagram default).
I can tell heif-convert to emit PNG, which resolves this issue in all versions (!!), but that causes conversion time to take 3-5x longer (on my workstation, about 1s for heif->jpeg for a typical iPhone 13 image, and 4-5s for heif-png for the same image.
I think for now it’s safest to just take the performance hit to resolve the issue for all cases and all versions.
When will this bugfix be available?
Version 2.1 includes this fix, and a fancy-pants operation to automatically repair the previews for impacted assets as soon as you upgrade.
Alpha builds of Version 2.1 will be released soon (hopefully this week).