The constant offset once in motion would appear inconsistent with a loss of the sin or cos output alone as far as I understand the use of those functions to derive the A-D output state. Contend as previously commented that the sensor itself is unlikely to be the component that has the fault, which leads to the install, wiring, or processing of the signal as being the point of failure. The loss of a single resolved output is intriguing, giving an erroneous result but it would appear that the offset error would alter with the change of actual AOA. The aircraft was operated from low speed, through to high speed, with substantial change in actual AOA, but the offset appears to be constant.
There are not many failure modes which may cause such a constant deviation. If normal checks are in place, it rules out everything except wrong calculation within or after atan(sin/cos). Cabling, loss of ground, ADC error... there are checks for such problems and they do not cause a constant offset.
Again, there are 2 possibilities left if I didn't miss something (I'm evaluating such resolvers for 2 safety relevant systems within electric cars at the moment):
-> Electromagnetic interference (EMI) at exactly the frequency the sensor is working on (or the sensor locks on the interference frequency with it's resonator) I tried to find a correlation between engine running/rpm and sensor failure but could not find any. EMI from the new engines would have been a nice one.
-> Error within the calculation after sin/cos and plausibilisation (sinē+cosē=1) -> Software change / bug?
The sin and cos voltage is simply the x and y of a 2D unit vector (look for 'unit vector' on english wikipedia, I'm not allowed to post a link) The receiver simply checks if the unit vector has a length of 1. If a cable breaks or the ADC has an error, it won't.
If there is no need to measure 360°, the electrical full circle is often a fraction of the mechanical one. So the electrical vector would make 2/3/4 turns on one mechanical revolution of the fin. Therefore 22.5° deviation could come from 90° signal error or calculation error. Those 22° somehow smell like some 90° computational error (e.g. wrong sign). Especially since atan calculations in old software only have a table for one quadrant of the unit vector and then switch signs or add/subtract 90°/180°/270°.
Switching cables (sin/cos) would btw. invert the angle (90°-x).
Still: If this sensor design is so bad, why is it still the same for the last decades? What changed on the MAX which tampered the probability of this error that much?
Without an answer to this question I would not trust the AoA signals (and many other) at all! (...and I'm a functional safety consultant)
This SW fix tries to fix the impact of the failure, the root cause seems to be still unknown. But without knowing the cause, other side effects cannot be identified.