Internally the stream implementation has a const '_BADOFF' which is equal to 0xffffffff, which is returned when the seek has failed. In this case the seek is succeeding, but the returned value from the seek is equal to the failure code, which results in the stream wrapper setting its fail-code erroneously.
_BADOFF is defined as a 64-bit type, it's just been assigned a stupid value.
As a workaround, you can seek 1-byte short, and then read a byte.
file.seekg(-1, std::ios::end);
char temp; file >> temp;
However note that this bug will manifest any time that particular file-offset is seek'd to, so it could still be a problem for larger files if you seek in them to random locations. For example if your file was one byte larger, this -1 seek would fail, so this is not a general solution.
The OP has extended their question, so I'll extend my answer. Yes, the seek value is cast using an unsafe conversion before the comparison. This doesn't seem to affect the ability to seek beyond that point in the file, as it's only used for comparison with the error value - the stream still has the right offset in it. However it does seem to be the root cause of _BADOFF being dubious in the first place, as _BADOFF is set to be '-1' in the source, and will suffer the same conversion, truncating to 0xffffffff.
So the fix for the libs might be to fix the cast (assuming there are no other side-effects of doing so), but for the sake of working around the problem, you only have to avoid seeking to positions where the bottom 32-bits are set. It'll seek beyond that OK, from what I can see.