SPI: MOSI not dropping LOW for receiving device
What might be the problem with the SPI? 


That scope trace suggests that there is another driver on the MOSI signal, in addition to the MCU.

That is bad, since MOSI typically uses a push-pull driver and multiple push-pull drivers will conflict, if they attempt to drive to different logic levels at the same time. As a result, you tend to see a "stepped" voltage like you see on your MOSI scope trace, when the different conflicting drivers change the logic levels that each is driving. (In the worst case, multiple drivers of the same signal can become permanently damaged, if they exceed their allowed maximum sink/source current through the opposing driver.)

It isn't as simple as MOSI being shorted to Gnd as we wouldn't then see it reach ~5V, nor is it shorted to ~5V since the signal is 0V at the start of the trace. There appears to be a low resistance (e.g. another device's output driver? a low value resistor?) pulling it up. (See below.)


  Is there a specific name for this problem?


Conflict between multiple drivers on the same signal. Your next step is to find out what else is driving that signal and why.

I browsed the encoder's datasheet. It is worth noting that it doesn't have a fixed SPI interface. It has a programmable serial interface, which can be SPI but can also be in other modes. I would check your programming of (and connections to) the encoder, to see if that is in a mode where it is driving the pin, which you believe is MOSI in SPI mode.

Notice how the MOSI signal starts at 0V, and goes to that ~3.5V level when -CS becomes active (low). Below, I have added a vertical white line onto your scope trace, to show that MOSI rises to ~3.5V at the same time as -CS is driven low, before the first clock pulse on SCK:



That correlation is a big hint that you are enabling the conflicting driver on the MOSI signal, when you drive -CS low. Assuming that the -CS signal goes only to the encoder, then that again makes the encoder the primary suspect.