FINERACT-2545: Implement client charge inactivation

[AshharAhmadKhan]

Description

POST /clients/{clientId}/charges/{chargeId}?command=inactivate has never worked. The API accepted the command and built a CommandWrapper with entity=CLIENTCHARGE and action=INACTIVATE, but no command handler was ever registered for the key "CLIENTCHARGE|INACTIVATE". The dispatcher threw UnsupportedCommandException immediately, returning HTTP 500 to every caller. The service method ClientChargeWritePlatformServiceImpl.inactivateCharge() was also a stub returning null with the comment // functionality not yet supported.

All the surrounding infrastructure was already in place — the DB columns is_active and inactivated_on_date exist in m_client_charge, the permission INACTIVATE_CLIENTCHARGE is seeded in 0002_initial_data.xml, the builder method inactivateClientCharge() exists in CommandWrapperBuilder, and the API routing at ClientChargesApiResource line 212 correctly accepts the command. The handler and service implementation were simply never completed.

Savings charges have had a fully working equivalent (InactivateSavingsAccountChargeCommandHandler) since MIFOSX-1408. Client charges were left behind.

Changes:

InactivateClientChargeCommandHandler.java — new handler registered under CLIENTCHARGE|INACTIVATE, modelled on WaiveClientChargeCommandHandler.

ClientCharge.java — added inactivate(LocalDate) domain method setting status = false and inactivationDate. The DB columns already existed, the method was simply missing.

ClientChargeWritePlatformServiceImpl.java — replaced the return null stub with a full implementation. Guards for already-inactive, already-waived, and already-paid states, followed by clientCharge.inactivate() and saveAndFlush.

ClientHelper.java — added inactivateChargesForClients() and getClientChargeField() test helpers.

ClientChargesTest.java — added clientChargeInactivateTest() covering the success path, the isActive field assertion post-inactivation, and the idempotency failure (inactivating an already-inactive charge must return 400).

Checklist

• 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.

[AshharAhmadKhan]

Pushed a follow-up commit after deeper review of state transitions and API completeness.

The first commit fixed the core bug - the missing handler and stub service. While verifying the full operation lifecycle I found three additional issues worth addressing in the same PR rather than leaving as separate tickets.

undoPayment() and undoWaiver() were unconditionally setting status = true, meaning undoing a prior payment on an inactivated charge would silently reactivate it. Fixed by checking inactivationDate == null before restoring active status, and added a service-level guard in ClientTransactionWritePlatformServiceJpaRepositoryImpl to block undo operations on inactive charges entirely - inactivation should be a terminal state.

isActive and inactivationDate were missing from CLIENT_CHARGES_RESPONSE_DATA_PARAMETERS, so ?fields=isActive returned nothing. Added both constants to the whitelist.

Updated the @Operation summary to document the inactivate command alongside pay and waive.

Tests added for the undo guard and the fields filter. All existing tests untouched.

[AshharAhmadKhan]

All checks should now be passing after squashing into a single commit.

Happy to make any adjustments based on feedback or direction from the ongoing discussion.