Fix reply memory leak in retryable command retry loop

[groeneai]

Problem

_mongoc_retryable_cmd_run (src/libmongoc/src/mongoc/mongoc-retryable-cmd.c) reuses *reply across retry attempts. Per attempt:

1. cmd->execute(...) populates reply (for a cursor read this ends in bson_copy_to(&body, reply) in _mongoc_cluster_run_opmsg_recv, allocating reply->own_buffer).
2. The loop inspects reply for retryability/error labels.
3. On a retry it calls cmd->select_retry_server(..., reply, ...) while reply still owns the previous attempt's allocation.

select_retry_server (cursor path: _retryable_cursor_commmand_select_retry_server -> mongoc_cluster_stream_for_reads -> _mongoc_cluster_stream_for_optype) treats reply as an out-param and, on its server-selection-failure path, overwrites it (bson_copy_to(&first_reply, reply) / bson_init(reply)) without freeing the prior contents. The loop's own bson_destroy(reply) sits after the if (!server_description) break;, so when selection fails it is never reached and the attempt's reply allocation is leaked.

Trigger: a retryable read error followed by a retry server-selection failure (a rare failover/topology race).

Fix

Destroy and re-init reply immediately before select_retry_server overwrites it, and drop the now-redundant trailing bson_destroy. This matches the existing bson_destroy; bson_init reset idiom in mongoc-cluster.c (OIDC reauth path). The reply-inspection reads all run before the destroy, so retry decisions are unchanged.

Verification

Observed in downstream (ClickHouse) CI as a LeakSanitizer 128-byte direct leak:

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    bson_malloc           src/libbson/src/bson/memory.c:106
    bson_copy_to          src/libbson/src/bson/bson.c:2106
    _mongoc_cluster_run_opmsg_recv  src/libmongoc/src/mongoc/mongoc-cluster.c:3313
    ...
    _mongoc_retryable_cmd_run       src/libmongoc/src/mongoc/mongoc-retryable-cmd.c
    _mongoc_cursor_run_command / _prime / mongoc_cursor_next

Reproduced deterministically with a standalone AddressSanitizer/LeakSanitizer harness that drives the real _mongoc_retryable_cmd_run with mock execute/select_retry_server callbacks matching the ownership pattern above: the leak is reported without this change and is gone with it.