FINERACT-2714: Add ability to exclude closed clients from client search results

[Samer-Melhem-FOO]

Description

The POST /v2/clients/search endpoint returns matching clients regardless of status, including closed ones, with no way for the caller to filter them out.

This adds an optional excludeClosed boolean field to the ClientTextSearch search request. When excludeClosed=true, the search excludes clients whose status is CLOSED (via a status != CLOSED predicate in SearchingClientRepositoryImpl). When omitted or false, behavior is unchanged — fully backward compatible for existing callers.

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

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 (not applicable — no new endpoint, just an optional field on an existing request DTO, already reflected via existing annotations)
• This PR must not be a "code dump".
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

[IOhacker]

@Samer-Melhem-FOO why no to exted to other client status?

[Samer-Melhem-FOO]

Thanks for the review! The scope here is intentionally narrow: this maps to a single UI checkbox — "Exclude closed accounts" — on the client search screen, not a general-purpose client-status filter.

The intent is just to let users hide closed clients from search results by default, since closed accounts otherwise clutter results for users who are typically looking for active/actionable clients. It isn't meant to generalize into filtering by arbitrary client status (pending, rejected, withdrawn, etc.) — that would be a bigger, separate feature with its own UI/UX (e.g. a status multi-select) and API design considerations, and isn't what this fix was scoped to solve.