Even if it’s not my place, as a newcomer, I will attempt a general explanation of these unexplained climb-aways, that seem to be unnervingly common. It’s highly speculative, since I don’t know the detailed internal working of the software, so take it for what little it might be worth.
Let’s assume that we have a drone that suffers from high vibration at a frequency above the lowpass filters (propeller rotation frequency). Based on my own experience with my quad, it seems that the vibe measurement, including clipping testing, doesn’t properly report this. It seems to report only the vibration that falls below the lowpass filter cutoff. If that is true (please, can someone tell if it’s true or not?), then it could very easily happen that the accelerometer is clipping from the high frequency vibration, and since the Z axis normally is at -9.8m/s², it will clip on the negative side long before it does so on the positive side. Instead in X and Y, which are normally at zero, any moderate clipping will typically be symmetrical, and thus cause no big error in the low-pass-filtered values.
If Z does clip, then the negative peaks will be shaved off, while the positive ones will not. So after the lowpass filter we get a more positive value than correct. And a more positive Z acceleration value normally means that the vehicle is accelerating downwards, which would obviously make the EKF calculate an altitude that drops ever faster (and indeed the CTUN.ALT shows that behaviour, in this case!), and trigger a throttle increase that makes the vehicle climb away.
I think that it would be important to make sure that accelerometer clipping is checked BEFORE lowpass filtering, sample per sample. That includes any lowpass filtering done in hardware - and this could be a limitation with any specific accelerometers implementing some lowpass filtering on-chip.
Also I think that it would be very important for the software to NOT trust the accelerometer above everything else. I mean, in this case the baro was correctly saying that the vehicle was climbing away, the GPS was saying the same, the climb rate determined by baro and GPS agreed very well, but still the software decided to disregard all that and say that the vehicle was descending and needed more throttle, apparently only based on very slightly wrong accelerometer data caused by high-frequency vibration and undetected accelerometer clipping, integrated over several minutes! That’s crazy. The correct data was available, from two independent sources, and the flight control software didn’t use it.