Okay, now that I am testing with a Chinese font (with PingFang SC as well), I see the problem system-wide. It looks like a Mac issue in general (at least with native software). You don’t need to use Scrivener at all to see it, you can save an RTF file in TextEdit, close it, and then open it, and they will be gone on all operating systems and text editors. That’s because the fault is in how it writes RTF.
So in taking a look at how the text engine writes the raw RTF to the disk (the below is TextEdit, but Scrivener is basically the same), we see the following (in excerpt):
\f0\fs24 \cf0 Line one
Line two
Line three\
\
\f1 Line one\uc0\u8232 Line two\u8232 Line three}
The first sample is in PingFang SC, and the second example is in a Latin-oriented fixed width font. You can clearly see the difference in output, where the Unicode character for a line break is being properly inserted after lines one and two, but in the first sample… nothing. The backslash at the end of a line is RTF shorthand for a newline, a paragraph break. As with HTML and many other markup languages, raw newlines in the file do not translate to the output. Without any kind of break in between these lines, they get glued together when loaded in an RTF reader.
Ultimately, because the Mac RTF writer is deleting any meaningful break characters from the output, there is nothing for Scrivener to even try to work with when reloading the file.
Best we can probably do is file it to Apple, and I would encourage likewise. Incidentally, this was all tested on macOS 26.5, so don’t bother considering upgrading from what you’re using, in the hopes it will be fixed.
Otherwise, the best hope I can think of is to keep trying different fonts, maybe something will work. I had slightly better luck with Noto Sans CJK SC, but not enough to call it reliable, which is why I speculate there might be something out there that is reliable.