FINERACT-1598: Remove unsupported recurringDepositFrequency fields from API docs

[Dhanno98]

Description

Implements FINERACT-1598: This PR fixes an inconsistency between the API documentation and backend validation for Recurring Deposit Product creation.

The fields recurringDepositFrequency and recurringDepositFrequencyTypeId are documented as supported request parameters in RecurringDepositProductsApiResource and RecurringDepositProductsApiResourceSwagger. But supplying these parameters results in validation errors.

This occurs because:

1. These fields are not present in DepositsApiConstants class which defines the valid JSON keys used for request parameter validation. The keys that we pass in the request JSON are compared against the set of valid keys from this class to check them for presence of any unsupported fields. Since these fields are not present as valid keys, we get validation errors.
2. These fields are not part of the domain model (RecurringDepositProduct), assembler (DepositProductAssembler), or any supported parameters used to construct a Recurring Deposit Product.

As a result these parameters are not used in building a RecurringDepositProduct and should not be documented as supported.

Changes

Remove both unsupported fields from:

1. OpenAPI @Operation documentation in RecurringDepositProductsApiResource.
2. Request Schema in RecurringDepositProductsApiResourceSwagger.

This aligns the API docs with the actual backend behavior.

Further Scope

The field charts is documented under Optional Fields in the OpenAPI @Operation documentation for the same POST body in RecurringDepositProductsApiResource. However, it is required for successful creation of a Recurring Deposit Product, and its absence results in a runtime validation error.
This may need a separate discussion.

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.

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

[Dhanno98]

I checked the Liquibase Backward Compatibility failure in liquibase-backward-compatibility-check logs.

The error seems to occur during migration in 0072_add_result_and_status_to_command_source.xml where the column processing_result_enum does not exist when upgrading from base branch schema.

This PR only updates OpenAPI or Swagger documentation and does not modify any database or Liquibase files. The failure seems to be unrelated to the changes in the PR.

I also searched JIRA for related issues but could not find an existing ticket. I have initiated the self-serve process for my JIRA account which is pending activation. Please let me know if you'd like me to create a JIRA once access is available or if there is an existing issue I should reference.