It's funny.
If I force SCI Companion to assume the pictures are in SCI1 format, they end up displayed as blanks, because they're not that format. Set the version detection to 1.1, and they appear fine. Same with SV's picture viewer. So mark that one down.
Looking at any random QFG1 picture's raw bytes in SV set to hex view, they all start with 0x26, marking them as SCI11 VGA, as per your code snippet, including #300.
Looking at my remade 300.p56 as a loose resource file, in a plain hex editor, I see this:00000000: 81 81 00 00 26 00 10 0E 01 00 A0 00 F0 D8 46 00
00000010: 9E 01 00 00 87 BE 00 00 00 00 00 00 00 00 00 00
The 0x26 appears at offset 0x04.
An SV-exported, otherwise clean 300.p56 has this:00000000: 81 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 26 00 10 0E 01 00
Note that the 0x26 doesn't appear until offset 0x1A.
I've always found the loose resources to be a little odd in that supposedly, the big difference between a loose resource and a packed one is that the loose one has a type identifier at the start, which is only two bytes. The header size is supposedly at 0x00, as per your ScummVM snippet, but much like with views it does not actually start at that point in the file, unlike for example vocabs, text, messages... Both of these are SCI11 pictures, too, so why do neither of them have the 0x26 where you'd expect it to be?
Y'know what actually fixed it and let me have a 300.p56 (the SV-exported one) without hanging? Changing the 81 80 at the start to 81 81.
But what's particularly interesting is that SV-exporting 84.p56 and renaming that to 300.p56 works fine without further trouble. For reference, it has 81 80 and the 0x26 byte is at offset 0x1A. Just like the hanging SV-exported 300.p56 has. Weird, huh?