This has nothing to do with Scribunto besides that Scribunto can be used to see it. A simpler test case, using eval.php:

$title = Title::newFromText( 'ThisDoesNotExist14' );
$wgHooks['TitleExists'][] = function ( $titleToCheck, &$exists ) use ( $title ) { if ( $titleToCheck->equals( $title ) ) { $exists = true; } };
var_dump( $title->getAllRestrictions() );

What's going on here appears to be:

• The process of previewing the page edit sets up a "fake" revision, so self-transclusion and such work right (see T7278 and T85408, for example). Part of this "fake" revision is using the 'TitleExists' hook to fake that the page being previewed exists, since it will when the preview is saved.
• Since the title supposedly exists, Title::loadRestrictions() loads restrictions from the page_restrictions table. Since the title doesn't have an actual page_id, it loads from page_restrictions for pr_page = 0.
• For some reason, frwiki has entries in the page_restrictions table for pr_page = 0. frwiktionary too, and 240 other WMF wikis. That's what you're seeing here.
• Scribunto's protectionLevels correctly reflects this incorrect protection data that was loaded for pr_page = 0.
• To make saving after a preview faster, the preview result is saved to be reused when the page is actually saved (gerrit:177514). This is probably what makes the saved page reflect the wrong protection until edited again or purged.

I don't see any way to determine when these bogus rows might have been added. Chances are the solution is probably to DELETE FROM page_restrictions WHERE pr_page = 0 on all wikis to remove these bogus rows, and then if they start showing up again we can start looking for a cause.

Thanks for digging into this.
One thing I forgot to mention: the issue does not occur with the parser function {{PROTECTIONLEVEL:edit}}.
Even if this is unrelated to scribunto, maybe the parser function does some kind of sanity checks that could be reused here?

In T119827#1843089, @Orlodrim wrote:

One thing I forgot to mention: the issue does not occur with the parser function {{PROTECTIONLEVEL:edit}}.
Even if this is unrelated to scribunto, maybe the parser function does some kind of sanity checks that could be reused here?

What seems to be happening there is that {{PROTECTIONLEVEL:edit}} winds up using the Title object from the Parser, which had its restrictions loaded before the page-preview logic sets up the hooks described earlier. If you do the seemingly-equivalent {{PROTECTIONLEVEL:edit|{{FULLPAGENAME}}}} to cause it to create a new Title object, you see the bug there too.

I have just tried to reproduce this bug, and I got the expected, correct value: "[]".