feat: Introduce a Unified Query API for Mirror Node Repositories

## Problem

While going through the [MirrorNodeClient](https://github.com/hiero-ledger/hiero-enterprise-java/blob/main/hiero-enterprise-base/src/main/java/org/hiero/base/mirrornode/MirrorNodeClient.java), I noticed that the number of query methods can grow quickly as more filters are added.

For example, TransactionRepository currently has methods like:

```
findByAccount(AccountId accountId)

findByAccountAndType(AccountId accountId, TransactionType type)

findByAccountAndResult(AccountId accountId, Result result)

```

These methods work fine for simple queries, but things can become difficult when multiple filters need to be combined together.

For example, a user may want to filter by:

Account + Type
Account + Result
Account + Type + Result
Account + Timestamp Range + Order

To support every combination, we would need to keep adding more repository methods. Over time, this could make the API harder to maintain and harder for developers to use.

## Proposed Solution

Instead of creating many method combinations, repositories could support a single query object that contains all filters.

Example:

```

Page findAll(TransactionQuery query);

```

The query object could use a builder pattern so developers can only add the filters they need.

Example:

```

TransactionQuery query = TransactionQuery.builder()
.accountId("0.0.1234")
.type(TransactionType.CRYPTO_TRANSFER)
.result(Result.SUCCESS)
.limit(20)
.order(Order.DESC)
.build();

Page transactions =
transactionRepository.findAll(query);
```

## Suggested Scope
1. Add query models

Create query classes under:
```
org.hiero.base.mirrornode.query
```
Examples:

TransactionQuery
NftQuery
AccountQuery

2. Update repositories

Add query-based methods like:
```
findAll(TransactionQuery query)
```

Existing methods can remain for backward compatibility.

3. Build query parameters dynamically

Update the REST implementations to generate URI parameters from query objects instead of fixed repository methods.

This could possibly be handled inside:

- MirrorNodeRestClient
- RestBasedPage
- or a shared utility class

please assign me this issue and i am open for discussion and your feedback.

Start by reading MirrorNodeClient, the existing repository methods such as TransactionRepository, and the REST implementations around MirrorNodeRestClient and RestBasedPage. Define the query models under org.hiero.base.mirrornode.query, update repositories and request construction as described, and preserve existing methods for backward compatibility; completion means combined filters can be passed through one query-based API.

Written by the indexing model from the issue text.