fix: widen the ClickHouse query bound until reads answer

[catinspace-au]

The release run for #249 failed its Test job in the gRPC outage suite. The cause is the fixed 30 s bound #249 put on every query: once a schema read takes longer than that, every attempt times out, the table's schema never loads and the pushed records never land.

Reproduced deterministically on 4673b76 with the new test below, which delays every schema read by 3 s under a 2 s bound: 0 of 20 records accepted in 60 s, after 4 retries. With this change it passes in about 20 s.

What changes:

• Queries run under one shared bound that doubles after each timeout, up to 300 s (the default ClickHouse gives its own socket reads and writes), and steps back down after a quick answer.
• The inserter's schema reads share that bound with the query client, so one slow read widens the next one wherever it happens.
• clickhouse.request_timeout_ms now defaults to 60000. It is the starting bound for queries and still bounds an insert waiting to hand over its next chunk.
• Inserts keep their own bounds and still go back to the hold on a timeout.

Tests:

• every_record_lands_when_schema_reads_answer_slower_than_the_request_bound (tests/integration/grpc_outage.rs): red on 4673b76, green here.
• Unit tests for the bound: widens after a slow read, stops at the ceiling, narrows after a quick answer, a base above the ceiling is its own ceiling.

Through a full outage the widened bound can hold one flush cycle past Kafka's 300 s max.poll.interval.ms. The consumer rejoins with the batch's offsets still uncommitted, so nothing is lost. CONFIGURATION.md says so.

[github-actions]

Released in v1.18.50 -- https://github.com/hyperi-io/dfe-loader/releases/tag/v1.18.50