Problems with decompiler splitting a 64-bit store into stores of two 32-bit floats

Version and Platform (required):

• Binary Ninja Version: 3.4.4137-dev (ebbd47c5)
• OS: macOS
• OS Version: 13.1 (22C65)
• CPU Architecture: M1

Bug Description:
This is a followup to #2805. It's stated to be fixed, but there are two problems.

First, going back to the original binary and repro instructions, I was hoping to get:

00000008      arg1->x = 384.0
00000008      arg1->y = 216.0

But I actually get:

00000008      arg1->x = 0x43c00000
00000008      arg1->y = 0x43580000

That is, the 64-bit store has been split into two 32-bit stores, but the values being stored are still shown as integers even though the struct fields x and y have type float.

Second, the splitting only seems to work when the store is at offset 0. Here is a binary with the same instruction sequence, except that the store is now at offset 0x100 from the pointer. So I create a struct containing:

0100    float x;
0104    float y;

and set arg1's type to a pointer to that struct. Again I expect to see:

00000008      arg1->x = 384.0
00000008      arg1->y = 216.0

But I actually get:

00000008      arg1->__offset(0x100).q = 27021602310848512.0

There is no split. Also, the presence of a 32-bit float as a struct field has caused Binary Ninja to decode the constant as a 64-bit float...

Start with the original reproduction from #2805 and the linked str2.zip binary, comparing decompiler output for stores at offset 0 and 0x100. Check how the typed float fields are represented in both cases. Done means both 32-bit stores display 384.0 and 216.0, including when the store is at offset 0x100, without decoding the constant as a 64-bit float.