FINERACT-2455: Working Capital - Consistent breach reprocessing & No backdated breach pause before reset

[alberto-art3ch]

Description

Two related changes to how breach actions reshape the breach schedule.

No backdated breach pause behind an active reset. A reset settles the breach
period it lands on and restarts the evaluation from its own date, while a pause
re-dates every period it precedes. A pause starting before the latest active
reset would therefore re-date periods the reset already settled, so it is now
rejected. Resets that were undone do not block, since the undo restores the
split. The reset's cut also has to survive the pause replay: it is applied after
the pauses, because a pause recorded inside the period before the reset would
otherwise re-open it.

Consistent breach reprocessing. Pause, resume and reschedule now go through
one replay of the recorded actions, in chronological order (start date, then
creation instant). Per period: the natural length of the parameters in force
over it, then the pauses it meets, then the cut of a restart reset landing
inside it. This fixes two defects in the reschedule path:

• a reschedule no longer re-dates periods that already closed under an earlier
  frequency — the parameters are resolved per period, from the reschedule that
  lands on it, instead of resolving the whole schedule against the latest one;
• the future periods a reschedule re-dates keep the pauses that fall in them,
  which the previous partial re-dating dropped.

The replay is idempotent, so a later action lands on the same schedule instead
of silently moving it. When the new action is the last one on the timeline only
the period it lands on and the ones after it are replayed; behind an already
recorded action the schedule is rebuilt from the start.

Covered by unit tests, integration tests and e2e scenarios. Breach actions are
replayed on their own timeline, so a pause may be backdated, but no scenario
moves the business date backwards.

FINERACT-2455

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

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

[adamsaghy]

LGTM