FINERACT-2723: Rename ambiguous domain-enum getters in StandingInstructionData

[Samer-Melhem-FOO]

Description

StandingInstructionData declares several fields of type EnumOptionData (fromAccountType, toAccountType, transferType, instructionType, recurrenceType, recurrenceFrequency). The class also declares same-named getter methods that return a different, internal domain-enum type instead, e.g.:

public PortfolioAccountType getFromAccountType() {
    return Optional.ofNullable(this.fromAccountType).map(e -> PortfolioAccountType.fromInt(e.getId().intValue())).orElse(null);
}

This is confusing to read and maintain: a field and its same-named "getter" disagree on type. No behavior or API change: StandingInstructionApiResource serializes this class via DefaultToApiJsonSerializer, which is Gson-based and reads the raw field directly regardless of these methods, so today's JSON output is unaffected either way — but the naming collision is still a latent correctness hazard (e.g. for anyone who later touches serialization, or adds a getter-based tool/library) worth removing.

Change: rename the six domain-enum helper methods to a distinct *Enum suffix (getFromAccountTypeEnum(), getToAccountTypeEnum(), getTransferTypeEnum(), getInstructionTypeEnum(), getRecurrenceTypeEnum(), getRecurrenceFrequencyEnum()) so they no longer shadow the field name, and add an explicit getter on each underlying field for consistency with the rest of the class. Internal callers (StandingInstructionApiResource, ExecuteStandingInstructionsTasklet) are updated to use the renamed methods, with added null-safety in toTransferType() since the domain-enum helper can return null when the underlying EnumOptionData field is null.

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

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.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

Note: pure internal rename with no behavior change, so no new test coverage was added; existing Standing Instruction tests continue to pass unmodified. No API documentation update needed since there is no API response change.