SPI clock rate is irrelevant as long as it doesn't exceed the max clock rate for the device, so 13MHz should be fine if you don't need any faster. I don't know what your system clock is, and even less so that of the corresponding APB, but your SPI clock can only be a fraction of it (by powers of two prescaler), so obviously you won't be able to generate just any frequency you want. You can adjust the APB clock though, doesn't have to be the same as the CPU clock.
As to the transfer, again your scope captures help figuring out what's wrong.
Now you can see there are actually TWO 16-bit transfers per call, which is not what you intended. (It will even actually overwrite things on the stack, which is bad. Here is why.)
I had to take a look at the HAL source code for HAL_SPI_Receive() to understand (maybe it's documented somewhere, but looking at the code was just much faster).
When the SPI peripheral is configured for 16-bit transfers, the Size parameter is actually NOT the size in bytes, but the number of 16-bit transfers.
Yeah, ST developers are nice like that, and produce consistent interfaces (ahem.) The fact that the parameter which is a pointer to the buffer is of type "uint8_t *" is completely misleading; it kind of makes you assume the Size parameter would naturally be the size in bytes. But nope. They should have declared the buffer param as "void *" instead IMO to make it less ambiguous (and it would not have required any annoying cast...), and they should have called the Size parameter something else. Oh well...
So in your case, you should pass ONLY 1 as the Size parameter, and a pointer to a uint16_t variable (like you did first), because the function actually writes the received data by 16-bit chunks (not sure if Cortex-M cores like unaligned accesses, but I don't really like them myself anyway.)
Passing 2 as the Size parameter, as you did, will issue TWO 16-bit transfers (which you can see on your scope). The second one will write somewhere on the stack that may have nasty consequences (basically you're unwillingly having a buffer overflow here.)