bug: etcd reads larger than 4 MiB fail at the client decoding limit

[Xuanwo]

OpenDAL version or commit

PR #8119 head b838b5fadb8eb5e53b77ae75bf574eef2914488e
(OpenDAL 0.58.2 in the reproduced CI job).

Affected service or component

services/etcd against etcd v3.6.4.

Describe the bug

The etcd service can write an 8 MiB value when the server allows it, but reading
the value fails because etcd-client 0.19.0 applies a default 4 MiB gRPC decoding
limit to KV responses.

This is a client response-size limit, not a write-size limit, so
Capability::write_total_max_size cannot describe it correctly.

Steps to Reproduce

Start the repository's etcd fixture:

docker compose -f fixtures/etcd/docker-compose-standalone.yml up -d --wait

export OPENDAL_ETCD_ENDPOINTS=http://127.0.0.1:2379
export OPENDAL_ETCD_ROOT=/tmp/opendal
export OPENDAL_TEST=etcd

cd bindings/dotnet
cargo build
dotnet test -f net10.0 \
  --filter 'FullyQualifiedName~ReadBehavior_LargePayload_RoundTripsExactly'

The fixture configures etcd with --max-request-bytes=10485760.

The failure is also reproduced in:
https://github.com/apache/opendal/actions/runs/32733492592/job/97459019848

Actual Behavior

Writing the 8 MiB value succeeds. Reading it fails with:

decoded message length too large: found 8388766 bytes, the limit is: 4194304 bytes

Expected Behavior

The 8 MiB round trip succeeds when the etcd server is configured to accept the
payload and the client decoding limit is configured accordingly.

Additional Context

etcd-client exposes KvClient::max_decoding_message_size, but OpenDAL's etcd
configuration currently provides no way to set it.

A fix should:

• Add an explicit etcd client decoding-size configuration without defaulting to
  an unbounded response size.
• Apply the configured limit to KV reads.
• Configure the repository's etcd fixture with a limit large enough for the
  existing 8 MiB behavior test.
• Remove the temporary etcd-specific skip after the behavior test passes.