However, clearly, iteration 3 had found a superior feasable solution.
That is not clear because the "Feasibility" metric is only displayed to a few decimal places. My first thought is to check the feasibility values to higher precision.
There is in any case rather little information here with which to diagnose. We would need to have the exitflag and other output information from fmincon to really make good guesses.
The program that ultimately calls on fmincon is a complex code written by someone else, that I don't understand fully. Could he have put some option to stop fmincon from returning the values at iteration 3 instead of the ones at the last iteration?
The input would definitely also help with diagnosis. You could set a breakpoint at the line of the code where fmincon is called. Then save all of its inputs to the base workspace (e.g., with this ) so that they can be run and studied separately. 
