FINERACT-2890: Keep accounting rule tags in AccountRuleRequest

[rymghosn]

Description

JIRA: https://issues.apache.org/jira/browse/FINERACT-2890

AccountingRuleApiResource#createAccountingRule / #updateAccountingRule bind the request body to AccountRuleRequest and re-serialize it before AccountingRuleCommandFromApiJsonDeserializer validates it. The record only declared name, officeId, accountToDebit, accountToCredit and description, so creditTags, debitTags, allowMultipleCreditEntries and allowMultipleDebitEntries were dropped during binding. As a result, a tag-based rule always failed with validation.msg.accountToCredit.or.creditTags.required / validation.msg.accountToDebit.or.debitTags.required, and the multiple-entry flags were ignored on update.

This change adds the four fields to the record. The command serializer omits null components, so account-based requests produce the same command JSON as before, and update keeps its "parameter present" semantics.

Tests

• New AccountRuleRequestSerializationTest (fineract-accounting) round-trips the record through ExcludeNothingWithPrettyPrintingOffJsonSerializerGoogleGson into the real create/update validators. It covers a tag-based request (tags and flags kept, validation passes), an account-based request (unchanged JSON, validation passes) and a request with neither (still rejected). 3/3 pass; spotlessJavaCheck passes.
• Live red/green against a local stock build (PostgreSQL, develop 4684c66380), two new AssetAccountTags code values as tags:
  • Red (develop's AccountRuleRequest): POST /v1/accountingrules {"name":"r1","officeId":1,"creditTags":[<a>],"debitTags":[<b>],"allowMultipleCreditEntries":true,"allowMultipleDebitEntries":true} → 400 with validation.msg.accountToCredit.or.creditTags.required and validation.msg.accountToDebit.or.debitTags.required. An account-based rule → 200.
  • Green (this change): the same request → 200; GET /v1/accountingrules/{id} returns both tags and allowMultiple*Entries: true; PUT swapping the tags with allowMultiple*Entries: false → 200 with all four in changes, and a re-GET shows them applied; an account-based rule still → 200.

API

No new endpoint. The POST/PUT /v1/accountingrules request schema (generated from the record via @Schema(implementation = AccountRuleRequest.class)) now also lists creditTags, debitTags, allowMultipleCreditEntries and allowMultipleDebitEntries, which the validator already accepted.

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 (no new API; the request schema picks up the fields from the record)
• 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.