FINERACT-2455: Working capital charge product disbursement

[budaidev]

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.

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

[galovics]

Scope note first: despite the title, this is product-definition only - the adoc says so explicitly. Disbursement charges can be created/updated/offered via the template API but aren't assessed during disbursement, inherited from the product, or touched in the amortization schedule. Worth confirming that's tracked as a follow-up JIRA, since the product becomes creatable in the meantime while the platform silently ignores it.

On the code itself, two real bugs on the update path:

1. chargePaymentMode is validated for WC charges but never persisted. The validation block checks ChargeAppliesTo.WORKING_CAPITAL_LOAN, but the assignment block a few lines down is gated on isLoanCharge() (ChargeAppliesTo.LOAN only) - so a WC charge's chargePaymentMode is validated, accepted, and then silently discarded. PUT /charges/{id} with chargePaymentMode set returns 200, reports nothing in changes, and the column stays whatever it was (nullable, defaults to NULL). The integration tests don't catch this because the only assertion on this field reads a NULL column back as 0 via ResultSet.getInt.

2. PUT with an explicit null chargePaymentMode is rejected, while POST accepts it. command.hasParameter(...) returns true for a JSON null, and isOneOfTheseValues treats a null value as a validation failure - so PUT with {"chargePaymentMode": null} 400s. The create path in ChargeDefinitionCommandFromApiJsonDeserializer explicitly guards against this (if (chargePaymentMode != null) {...}), and there's even a test pinning that exact behavior for POST (Order(23)) - but no equivalent guard or test on PUT.

Please pick a fix for #1 (either extend the persist block to WC, or explicitly reject the parameter on WC update) and add the same null-guard from the create path to Charge.java:524 for #2, plus a mirroring test.

Non-blocking: the penalty/overdue guard relaxation in update() also widens for savings/client/share charges, not just WC - unreachable via their own allow-lists today, but worth calling out explicitly in the commit message since it's broader than FINERACT-2455 strictly requires.

Recommendation: CHANGES_REQUESTED