Looking at the GPS coordinates, the second to last reading was ~200m before the seawall, while the last reading was around halfway down the runway.

The plane is far outside it's normal operating conditions by this point, it's possible the plane instruments actually experienced a brief moment of 'climb' while the plane was crashing, or it could be equipment malfunction.

However, from what I can tell, the plane never reached that far down the runway. And the gps coordinates have actually snapped to the middle of runway 19L, near where it intercepts 28L, suggesting that flight radar 24 are doing some post-processing to make the planes stick to runways better.

I wouldn't trust that last data-point at all, as it's definitely post-seawall.

Looking at the data, it's obvious that the vertical velocity figures are not anywhere near as accurate as "120" would indicate.

The data points are in the neighborhood of 15 seconds apart. There are 4 points labeled 2:25PM, 3 points labeled 2:26PM, and 5 points labeled 2:27PM.

The altitude data is all rounded to the nearest 100ft. Obviously this is coming from transponder data. The mode C transponder carried by an airliner reports pressure altitude back to the interrogating radar at 100ft intervals.

Vertical velocity is all multiples of 60fpm. I have no idea where that would be coming from. As far as I know, vertical velocity is not transmitted by either radar transponders nor the newer ADS-B position broadcasting equipment. Simply taking the derivative of reported altitude wouldn't produce these results, because with 100ft altitude intervals and 15s reporting intervals, that gives you a vertical velocity resolution of only 400fpm.

Let's skip that question for the moment. The raw altitude data does show an increase from 100ft to 200ft at the end. But what conclusion can we draw from this? Essentially nothing. Because the altitude is so quantized, this could in theory indicate anything between a 0ft and 200ft increase in altitude, non-inclusive. Of course, the instruments are not that precise, so in practice the range is even larger. This is especially true given that the instrument was in the middle of a fairly violent plane crash when it gave that last reading. From the video of the crash, it's clear the plane never got very high above the runway. Since the runway is only 13ft above sea level, and the plane didn't crash into the ocean, the amount of climb possible is very much limited. The transponder may well have increased in altitude a bit for this last reading, but if so, the alignment with the reported altitude increase is pretty much just coincidental.

Now back to the vertical velocity. Where did it come from? I can only speculate that they're applying some kind of curve-fitting or smoothing to transform the coarse altitude data into smoother vertical velocity figures. These numbers are therefore even less reliable than the altitude figures, and can probably just be ignored.

Just to briefly support that last bit, there are some obvious numerical anomalies in the vertical velocity figures earlier in the flight. At 9:38AM, the data source briefly switches from "FlightAware Transoceanic" to "Oakland Oceanic" and then back again. The two Oakland data points show an altitude of 37,000ft, while the FlightAware data shows 34,000ft. The vertical velocity for these four points is shown as 2280fpm, 9960fpm, -4320fpm, and -1800fpm. These changes obviously didn't actually happen (otherwise we'd have heard about people being flung about the cabin in mid-flight!) and are just some sort of reporting anomaly. The ridiculous vertical velocity figures (nearly 10,000fpm climb accompanied by a minor increase in horizontal speed!) are obviously just some sort of post-processing going crazy trying to fit the bad altitude data.