have you doublechecked the cart to make sure that the magma (and the weight of the magma!) has been correctly removed?
I'm thinking maybe a bug with the minecart's magma-unloading.
No problems with unloading - you can see that the middle three tiles of the left channel are red. That's magma from the first two or three revolutions before the cart got stuck.
While you've clearly solved your practical problem well enough, I'm still curious about the cart getting stuck after 3-4 revolutions.
My bug comment wasn't about the magma not getting unloaded - I did see that, yes - but about magma unloading having a bug on the coding side. The fact that the minecart always stopped at 3 or 4 revolutions does suggest that the bug has something to do with fullness.
My hypothesis, without actually looking into the properties of minecarts cause I don't know how:
We already know that weight has an effect upon momentum. Heavier carts travel further on any given push. If the liquid level for momentum purposes is stored in a single byte, and there is a bug where that byte doesn't get reset to 0 when the magma is dumped, then the journey of your minecart would be as follows:
Start: Minecart momentum calculations believe it is at 0/7.
Round 1, starts at 0 liquid, gains 2 liquid, rolls uphill, dumps 2 liquid. Minecart momentum calcs believe it is 2/7.
Round 2, starts at 0 liquid, gains 2 liquid, rolls uphill, dumps 2 liquid. Minecart momentum calcs believe it is 4/7.
Round 3, starts at 0 liquid, gains 2 liquid, rolls uphill, dumps 2 liquid. Minecart momentum calcs believe it is 6/7.
Round 4, starts at 0 liquid, gains 2 liquid, rolls uphill, dumps 2 liquid. Momentum calc fluid level
overflowsto 0/7, because in single-byte arithmetic 6+2=0. It therefore doesn't have enough momentum to push the minecart's weight up the ramp.
Just my two cents.