opus roundtrip - glitch at the end of the file

Hi OPUS developers,

We are seeing weird behavior at the end of opus files. We are trying to write artificially-constructed sine-wave-based data (for testing) that looks something like this:
expectedData.txt

We are seeing that difference between the data we are writing ("expected" data) and the data we read back ("actual" data) are especially bad at the end of the file. E.g.:

Note that apart from the end of the file, "actual" data matches "expected" data pretty well.

We thought it might be due to the end of the data containing smaller-amplitude signal that is too close to noise and seem perceptually irrelevant.

But somebody with more audio signal processing expertise also mentioned that it could be because of time-domain aliasing and related to OPUS being MDCT-based. We tried adding 1024 samples of silence at the end, but we still see a little bit of the glitch:

Zoomed in view on just the silence and the glitch:

Note that we are using opus through libsndfile library.

Does this look expected based on how OPUS codec works or does it look like a bug? I might be able to provide simplified libsndfile repro steps if further investigation is necessary.

Note that we are also seeing a bit of numeric difference between data read on Intel Mac and Apple Silicon Mac, and noticing this glitch came out of that investigation (that difference seemed much worse on the "glitch" part of the file). We assumed this difference between Intel Mac and Apple Silicon Mac machines might be ok otherwise.

Start by preparing the simplified libsndfile reproduction mentioned in the report, using the provided expected data and the OPUS roundtrip. Compare the end-of-file samples and the Intel Mac versus Apple Silicon results, then determine whether the glitch is expected codec behavior or a reproducible bug. Done means documenting the cause and a minimal reproduction or confirming the behavior is expected.