The reconciliation is a Knapsack problem - Wikipedia the current implementation is a naive brute force because we expected only small number of payment terms (certainly not 45 terms). Some heuristics exits that may find a solution faster.
But I think the problem is that having a payment terms of 45 lines is the real problem. With a term per month, it spreads over almost 4 years. I do not know business that can take such risk.
That can not be a solution because the problem will still be there: no reconciliation or payment.
I do not see how this could solve the problem. Indeed with recursion you will probably reach recursion limit.
Maybe an option would be to raise a warning when calling Invoice.get_reconcile_lines_for_amount with a list of lines to big (biggest than reconciliation_chunk). So the user will have to remove the invoice (or not use the pay wizard) and make the reconciliation manually (create the payment move manually).