FINERACT-2690: Fix undo account transfer to resolve and scope by tran…

[Samer-Melhem-FOO]

AccountTransfersWritePlatformServiceImpl.undo() had two related defects, discovered while testing the undo-account-transfer capability added in FINERACT-2604 and extended in FINERACT-2613:

1. Wrong lookup table. The endpoint's path id was resolved against m_account_transfer_details, but AccountTransfersReadPlatformServiceImpl.retrieveOne (which backs the transfer read/list APIs) queries by m_account_transfer_transaction.id. These are two
   independent, unrelated id sequences that drift apart over time, so a caller undoing a transfer they can clearly see via the list/read endpoints could get a 404.
2. Over-reversal on recurring transfers. undo() reversed every AccountTransferTransaction tied to the resolved AccountTransferDetails record, rather than only the single transaction the caller asked to undo. This incorrectly reversed every execution of a
   recurring transfer (e.g. a standing instruction) sharing one details row across many runs.

This PR fixes undo() to resolve and scope by m_account_transfer_transaction id instead, for both the savings-to-loan and savings-to-savings paths, so:

• the id passed to undo matches what the read/list APIs actually expose, and
• only the specific transaction requested is reversed, leaving sibling executions of a recurring transfer untouched.

It also adds the missing UNDO_ACCOUNTTRANSFER permission (entityName=ACCOUNTTRANSFER, actionName=UNDO) via a new Liquibase changelog part — the command handler was already wired to check this permission, but no matching m_permission row was ever shipped, so
the command failed permission validation before reaching the (buggy) logic above.

[adamsaghy]

@Samer-Melhem-FOO Please rebase this PR.

[adamsaghy]

LGTM

[Samer-Melhem-FOO]

Rebased onto latest develop. Also had to renumber the new changelog part from 0242 to 0244 to avoid colliding with 0242/0243 that landed on develop in the meantime.

[AshharAhmadKhan]

hey @Samer-Melhem-FOO please resolve conflicts and rebase, thanks!

[Samer-Melhem-FOO]

Rebased onto latest develop and resolved the conflict in changelog-tenant.xml (renumbered the new changelog part to 0245 to avoid colliding with 0244_add_payment_detail_to_account_transfer_transaction.xml). Ready for another look.

[AshharAhmadKhan]

hey @adamsaghy please review this when you get a chance, thanks!

[AshharAhmadKhan]

Hey @Samer-Melhem-FOO please rebase to latest upstream andd resolve changelog conflicts.

[Samer-Melhem-FOO]

Rebased onto latest develop and resolved the changelog conflict — 0245_add_undo_accounttransfer_permission.xml was renumbered to 0248 since 0245-0247 were already taken upstream. Force-pushed.

[Samer-Melhem-FOO]

FYI @AshharAhmadKhan @adamsaghy

[adamsaghy]

@Samer-Melhem-FOO Can you please review the failing checks?

[adamsaghy]

@Samer-Melhem-FOO Please rebase and fix the failing checks

[adamsaghy]

@Samer-Melhem-FOO Are you planning to finish this PR?

[Samer-Melhem-FOO]

@adamsaghy Rebased onto latest develop (renumbered the new changelog part from 0248 to 0254 to avoid colliding with 0248-0253 that landed upstream in the meantime) and fixed the actual CI failure: AccountTransferOverdraftTest.preserveTransferLinkWhenBackdatedDepositRecalculatesOverdraft() was calling undo() with the create-command's resourceId (m_account_transfer_details.id) — the old, buggy id space this PR's fix stops accepting. Updated it to use the transfer-transaction id instead, which is what undo() now correctly requires. Force-pushed, ready for another look.

[AshharAhmadKhan]

@Samer-Melhem-FOO please check the failing logs

[AshharAhmadKhan]

@Samer-Melhem-FOO please check the failing logs

[adamsaghy]

@Samer-Melhem-FOO Please rebase and check failing checks.

[Samer-Melhem-FOO]

@adamsaghy Rebased onto the latest develop and force-pushed. The rebase was conflict-free this time, and 0254_add_undo_accounttransfer_permission.xml is still free upstream, so no renumbering was needed.

I also pushed a second commit that was missing: AccountTransferOverdraftTest.preserveTransferLinkWhenBackdatedDepositRecalculatesOverdraft() was still calling undo with the create-command's resourceId (an m_account_transfer_details.id) instead of the transfer-transaction id this PR's fix requires. It now passes withdrawal.getTransfer().getId(), which the savings transactions mapper populates from m_account_transfer_transaction.id — the same key space AccountTransfersReadPlatformServiceImpl.retrieveOne looks up (where att.id = ?). It passed before only because both id sequences coincide in a fresh test database.

On the two failing checks in the previous run: both looked like CI infrastructure rather than this PR.

• E2E Tests (Shard 9 of 20) — the fineract container never became healthy (curl … localhost:8443 returned SSL_ERROR_SYSCALL through all 30 retries), and the gradle invocation also hit Failed to load eclipse groovy formatter: java.lang.IllegalArgumentException: 502 at https://download.eclipse.org/eclipse/updates/4.29/…/com.sun.jna_5.13.0.jar.
• regression-safety — ended with The runner has received a shutdown signal … The operation was canceled. before it got to the changelog checks.

All 85 other checks were green, including every MariaDB integration shard. Locally on the rebased branch, :fineract-provider:compileJava and :integration-tests:compileTestJava both build clean and spotlessJavaCheck reports no violations in the touched files. Hopefully this run comes back green — happy to dig in if anything real shows up.