FINERACT-2455: Working Capital loan mark as fraud

[alberto-art3ch]

Description

Adds a mark-as-fraud command to the Working Capital Loan module, mirroring the Term Loan fraud flag. A loan can be flagged/unflagged as fraudulent

• New endpoint: PUT /v1/working-capital-loans/{loanId}/mark-as-fraud with body {"fraud": true}
• Typed request/response DTOs, command, handler (with resilience4j @Retry) and write service
• Liquibase changeset: is_fraud column + SETFRAUD_WORKINGCAPITALLOAN permission
• Read model + Swagger expose fraud; feature documented in fineract-doc
• Integration test via the generated Feign client (mark/unmark, idempotency, required-field validation)

FINERACT-2455

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.

[Aman-Mittal]

@ ApiResponses(

Use ApiResponse( only or use multiple ApiResponse annotation in case of multiple

[Aman-Mittal]

minor: TextBlock

[galovics]

This routes a sensitive flag change through Fineract's brand-new typed command framework instead of the legacy command-source pipeline every other WC command uses.

WorkingCapitalLoanApiResource.java:

// Permission code = <action>_<entity>. The new command framework does not enforce per-command permissions,
// so the mark-as-fraud endpoint checks it explicitly to keep parity with the legacy authorization model.

Auth is handled explicitly here so that's fine, but I checked the framework's own docs (fineract-doc/.../command/audit.adoc is literally TBD, and refactoring.adoc says maker-checker "will be part of a separate proposal") - this command gets no audit trail and no maker-checker, unlike every other WC command in this whole epic which goes through the legacy pipeline and gets both for free. Marking a loan fraudulent seems exactly like the kind of action you'd want an audit trail on. Is it worth waiting for command-audit to land before routing this one through the new framework, or is that an accepted tradeoff?

Minor: the PR also adds a full new charge-off.adoc doc chapter describing the general (non-WC) Loan Charge-Off feature. Reasonable context to set up the "Fraud Charge-Off" section, but it's documenting a whole pre-existing shared feature, not really "Working Capital loan mark as fraud" - could've been its own doc PR.

[alberto-art3ch]

This routes a sensitive flag change through Fineract's brand-new typed command framework instead of the legacy command-source pipeline every other WC command uses.

WorkingCapitalLoanApiResource.java:

// Permission code = <action>_<entity>. The new command framework does not enforce per-command permissions,
// so the mark-as-fraud endpoint checks it explicitly to keep parity with the legacy authorization model.

Auth is handled explicitly here so that's fine, but I checked the framework's own docs (fineract-doc/.../command/audit.adoc is literally TBD, and refactoring.adoc says maker-checker "will be part of a separate proposal") - this command gets no audit trail and no maker-checker, unlike every other WC command in this whole epic which goes through the legacy pipeline and gets both for free. Marking a loan fraudulent seems exactly like the kind of action you'd want an audit trail on. Is it worth waiting for command-audit to land before routing this one through the new framework, or is that an accepted tradeoff?

Minor: the PR also adds a full new charge-off.adoc doc chapter describing the general (non-WC) Loan Charge-Off feature. Reasonable context to set up the "Fraud Charge-Off" section, but it's documenting a whole pre-existing shared feature, not really "Working Capital loan mark as fraud" - could've been its own doc PR.

PR updated to use legacy command handler