FINERACT-2703: Validate required datatables based on legal form during client creation

[Samer-Melhem-FOO]

Summary

• When an "Entity Datatable Check" is configured to be required only for a specific client legal-form sub-type (Person or Entity), client creation for the other sub-type incorrectly failed with "Datatable cannot be empty", even though no datatable check actually applies to that sub-type.
• Root cause was twofold:
  1. EntityDatatableChecksWritePlatformServiceImpl.runTheCheck(...) upper-cased the entitySubtype before looking it up (entitySubtype.toUpperCase()), but the value is stored verbatim (e.g. "Person", "Entity", matching LegalForm.getLabel()), so the lookup could silently return nothing.
  2. ClientDataValidator.validateForCreate(...) unconditionally required the datatables JSON array to be non-empty whenever the datatables parameter was present in the request, regardless of whether any datatable check actually applies to the submitted legal form.
• Fix: removed the erroneous .toUpperCase(), and added areDatatablesRequiredForLegalForm(...) so the non-empty datatables check is only enforced when at least one EntityDatatableChecks record is actually configured for the client's legal-form subtype (or globally, when no subtype is set).

Test plan

• Extended ClientDataValidatorTest with 2 new tests:
  • validateForCreate_withEmptyDatatables_whenNoneRequiredForLegalForm_doesNotThrow
  • validateForCreate_withEmptyDatatables_whenRequiredForLegalForm_throwsPlatformApiDataValidationException
• All 11 tests in ClientDataValidatorTest pass
• ./gradlew :fineract-provider:compileJava :fineract-provider:compileTestJava — builds clean
• ./gradlew :fineract-provider:spotlessApply — no formatting drift beyond this change
• Manual verification: configure a Person-only required datatable, create an Entity client without datatables, confirm it now succeeds

https://issues.apache.org/jira/browse/FINERACT-2703

[Samer-Melhem-FOO]

The only failing check here is run-integrations-tests-on-mysql / MySQL Tests (Shard 3 of 15). It fails at the jibDockerBuild step, before any tests run:

I/O error for image [registry-1.docker.io/azul/zulu-openjdk-alpine]:
java.net.SocketException
Connection reset

This is a transient Docker Hub registry connectivity issue on the runner, unrelated to this PR's change. All 14/15 other MySQL shards, all MariaDB/PostgreSQL shards, and every other check passed.

Could a maintainer re-run the failed job? Thanks!