FINERACT-2455: Fix COB amortizing discount fee before payment, fix WC loan closedOnDate wrong when backdated transaction closes

[Cocoa-Puffs]

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.
• I followed the AI Policy.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[adamsaghy]

Please review the below findings / concerns:

the undoTransaction call site is a no-op in the case it was added for

WorkingCapitalLoanTransactionProcessor.recalculateClosedOnDate's javadoc says it "must be called wherever determineAndTransition can stamp a closure … the repayment path here, a discount fee adjustment, and a transaction undo", and the PR duly adds it at WorkingCapitalLoanWritePlatformServiceImpl.java line 1145. That call can never fire there:

• undoTransaction transitions with DateUtils.getBusinessLocalDate(), so any closure it stamps carries today's date.

• Future-dated transactions are rejected (WorkingCapitalLoanDataValidator), so MAX(repayment date) <= today, and the isBefore guard is always false.

The reachable case it would need to fix is the mirror image: validateUndoTransaction explicitly allows OVERPAID, so undoing an overpaying repayment that leaves the loan exactly settled fires LOAN_REPAID_IN_FULL and stamps closedOnDate = the undo day, while maturedOnDate keeps the earlier date it got when the loan first went overpaid. You end up with timeline.closedOnDate after timeline.actualMaturityDate — the drift the settlementDate javadoc says these two should not have. Pre-existing, not a regression, but the javadoc currently overstates what the call does.

Smaller, same shape: recalculateClosedOnDate returns early unless isClosedObligationsMet(), so on the overpaid path maturedOnDate is never corrected. A backdated repayment tipping a part-paid loan into OVERPAID leaves actualMaturityDate at the backdated date even though recalculateOverpaidOnDate fixes overpaidOnDate and settlementDate uses the corrected value for the amortization.

[Cocoa-Puffs]

Both findings turned out to be correct. recalculateClosedOnDate(loan) became recalculateSettlementDates(loan, statusBeforeEvent), covering the OVERPAID branch as well as the closed one. I've extended the repository query to return the date of the newest live repayment-like transaction whose allocation is not entirely overpayment.

The overpaid branch can now set this date directly.

The closed branch now considers whether the loan was overpaid going into the current transaction processing, if prior the loan was overpaid and now it is simply closed it means that the current transaction is takins some sort of excess away. In this case the obligationMetOnDate is assigned outright, meaning they can move "earlier" as the loan is falling back onto a settlement that already happened.

Otherwise the event is what settled the loan, and it may not have been a repayment. Each date only moves later, never earlier, so a settlement completed by a non-repayment keeps the transition's own date.

I also added 2 new integration tests, that test for the mirror scenario you described.