[client-v2] Allow QuerySettings in POJO queryAll overloads

Hi! This is my first issue in this repository, so apologies if I did not formulate the idea perfectly.

I'm also not completely sure whether this API change is technically appropriate or possible. There may be a reason why `QuerySettings` cannot or should not be passed to the POJO `queryAll` overloads. If so, I would be happy to understand the reasoning.

### Description

The experimental POJO `queryAll` API currently does not provide an overload that accepts `QuerySettings`.

Current overloads:

```java
queryAll(String sqlQuery, Class clazz, TableSchema schema)

queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
Supplier allocator
)
```

Internally, the method creates its own QuerySettings:

```java
QuerySettings settings =
new QuerySettings()
.setFormat(ClickHouseFormat.RowBinaryWithNamesAndTypes);
```

Because of that, callers cannot provide query/server settings such as:

- limit
- page
- max_execution_time
- query id
- database
- other operation-level server settings

At the same time, queryAll for GenericRecord already accepts QuerySettings and copies the supplied settings while forcing the response format to RowBinaryWithNamesAndTypes.

It would be useful if the POJO overloads supported the same behavior.

Proposed API

For example:
```java

public List queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
QuerySettings settings
)

public List queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
QuerySettings settings,
Supplier allocator
)

```
The response format should still be controlled internally by queryAll, since POJO deserialization depends on RowBinaryWithNamesAndTypes.

In other words, the provided settings could be copied and then:

```java
requestSettings.setFormat(
ClickHouseFormat.RowBinaryWithNamesAndTypes
);
```

This would keep POJO deserialization safe while allowing callers to use settings such as pagination, execution limits, query id, database, etc.

Why

This would make the POJO queryAll API consistent with the existing GenericRecord queryAll API and would avoid forcing callers to reimplement the POJO deserialization path only to pass custom QuerySettings.

Locate the experimental client-v2 POJO queryAll overloads and the existing GenericRecord queryAll overload that accepts QuerySettings. Read those entry points first, then inspect the surrounding queryAll tests. Done means both proposed POJO overloads accept copied settings while still forcing RowBinaryWithNamesAndTypes, with coverage for the supported settings and deserialization behavior.

Written by the indexing model from the issue text.