FINERACT-2579: Batch entity lookups in generateLoanProvisioningEntry to eliminate per-row DB calls

[AshharAhmadKhan]

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

The generateLoanProvisioningEntry() method in ProvisioningEntriesWritePlatformServiceJpaRepositoryImpl was firing five individual repository queries per loop iteration — LoanProduct, Office, ProvisioningCategory, and both GLAccount entries — for every row returned by retrieveLoanProductsProvisioningData(), causing N×5 redundant DB round-trips on every provisioning entry creation or recreation request.

Since all referenced IDs are known before the loop begins, this fix collects them upfront and replaces the individual lookups with four bulk findAllById() calls, reducing the total round-trips from N×5 to 4 regardless of entry count. In-memory map lookups replace the per-row DB calls inside the loop.

This is the same class of redundancy fixed in FINERACT-2561 for saveAllDebitOrCreditEntries(), but more severe — five queries per iteration instead of one, on a batch job path that processes every active loan product across all offices.

No logic change — all entity resolution still happens, and proper Fineract exceptions (LoanProductNotFoundException, OfficeNotFoundException, GLAccountNotFoundException) are thrown if any entity is missing. OfficeRepositoryWrapper is replaced with OfficeRepository directly to enable bulk fetching.

[AshharAhmadKhan]

hey @adamsaghy

All the failing checks look like infra issues (eclipse cdn 502s and docker startup timeouts), nothing related to my changes. can you rerun them when you get a chance please?

[AshharAhmadKhan]

@adamsaghy

still eclipse cdn 502s, nothing to do with my changes. would appreciate a code review when you get a chance!

[AshharAhmadKhan]

failing test is unrelated to PR. PR is ready for review.