2.145.0 causes MaxIters in MTK optimization problem

Updating my packages suddenly had my optimization code take 70X longer than before, and fail with `MaxIters`. [Bisecting the registry](https://discourse.julialang.org/t/bisecting-regressions-across-dependencies/135985/6) designates ```julia [0bca4576] ↑ SciMLBase v2.144.2 ⇒ v2.145.0 ``` as the culprit. Before that update (on SciMLBase v2.144.2): ```julia julia> @time res, _, sol = run_optimization(sim); 0.730308 seconds (10.20 M allocations: 291.045 MiB, 27.10% gc time, 9.77% compilation time) ``` with a successful return code, while after that update (on SciMLBase v2.145.0), ```julia julia> @time res, _, sol = run_optimization(sim); 53.272994 seconds (1.42 G allocations: 34.099 GiB, 9.24% gc time) julia> res.retcode ReturnCode.MaxIters = 4 julia> res.stats SciMLBase.OptimizationStats Number of iterations: 3000 Time in seconds: 53.215000 Number of function evaluations: 44051 Number of gradient evaluations: 3002 Number of hessian evaluations: 0 ``` All timings are for warm JIT. (worryingly, I also saw return codes of `SciMLBase.ReturnCode.Infeasible` pop up during the bisection) `run_optimization` performs constrained optimization of a fairly vanilla MTK model using Ipopt and AutoForwardDiff, following https://docs.sciml.ai/ModelingToolkit/stable/examples/remake/. I am quite confident that the problem has a single optimum. #### Registry bisect log ``` git bisect start 'eb858dc5b9d' '5f08671057b' git bisect good 347f4cc60990dfc9dff686ad2f6b7f81e2bea24d git bisect bad 6600297d1d03fdc3b619056f04547332a24491e5 git bisect good cc83a43779c53abe1172dca7c78ee4e61593767f git bisect good 8f8b07927f42c56ff47582e0a967b6267b0c4077 git bisect bad ffdb90c3bcefe4137426d90955ee5653163e711d git bisect good d02eebb97ff81debd95b1a95324c94ee7e759991 git bisect good 64774d9d0862ec28d402fe0e0c574c344525a3e6 git bisect good ac02530260f4005ffdf630b08e00ec4b31b7c13f git bisect good 812bf925db3446d7d225116f556dc2a5913550c9 git bisect bad dda9eb05c7ced14e680903dbf964b1b3efa2ba31 git bisect good 2a0a9e18e42a524e07fbd6b4c83aa770c210adaa dda9eb05c7ced14e680903dbf964b1b3efa2ba31 is the first bad commit ```