This is a follow-on to this post.
It turns out it was an error on my part! (Kind of what I expected, but maybe you expected it, too, reader!)
The problem was with how the heif2jpg utility is writing out the decoded pixels to the output file or memory; the stride of the decoded image did not match the width of the final image! And my mistake was thinking they must match when it appears that they very much don't have to.
In the example 1620x1080 image that I was using, the width of the final image is 1620, but the stride of the decoded image was 1624, and the "pic width in luma (Y) samples" in the original encoded image was 1632. The first two numbers are what's important; there are extra empty pixels that can be skipped when copying the values over to the new image array/file.
It looks stupid now that I see it, and I'm embarrassed that I only figured this out after stepping through the debugger and looking at the details of the SPS (Sequence Parameter Set) header from the HEVC codec, but this should mean it will handle future images of any size...?
I haven't pushed the fix yet, but I will soon, and so then I can move onto other things -- maybe an Android app that will convert the HEIF files from Snapbridge into JPEGs as they're received from the camera?