FINERACT-2665: Fix NPE modifying a loan application when schedule fields are omitted

[oluexpert99]

• On modify, LoanScheduleAssembler.assembleLoanApplicationTermsFrom rebuilds the loan terms from the request
  JSON. A modify request may legitimately send only the fields being changed (LoanApplicationValidator
  .validateForModify already treats the rest as optional), but the recalculation read each schedule-driving
  field straight from the request: an omitted override-enabled enum hit XxxMethod.fromInt(null) and an omitted
  expectedDisbursementDate hit deriveFirstRepaymentDate(null), both throwing a NullPointerException (HTTP 500)
  once the change triggered a schedule recalculation. This completes FINERACT-2389, which applied null-override
  handling only to the grace/tolerance fields.
• Before recalculating, backfill any omitted schedule-driving field from the loan's own values
  (LoanAssemblerImpl.updateFrom -> backfillOmittedScheduleTerms) so the regenerated schedule matches what the
  loan records rather than a product default or null: interestType, amortizationType,
  interestCalculationPeriodType, repaymentEvery, numberOfRepayments, repaymentFrequencyType, loanTermFrequency,
  loanTermFrequencyType, interestRateFrequencyType, graceOnPrincipalPayment, graceOnInterestPayment,
  graceOnArrearsAgeing, principal, interestRatePerPeriod, expectedDisbursementDate, submittedOnDate and
  interestChargedFromDate. This mirrors validateForModify, so validation and recalculation stay consistent.
• Date fields are re-serialised with the request's own dateFormat/locale, exactly as loan creation requires
  them; if a date must be backfilled and either parameter is missing or malformed, fail with a clear
  validation error rather than defaulting.
• Add unit tests for the backfill helper, the date-formatter required-parameter handling, and the
  schedule-term backfill from a loan.

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

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.