admin: fix use-after-free in coord_request error path

[Piotr WOLSKI (piochelepiotr)]

Description

Fix a use-after-free bug in rd_kafka_admin_coord_request() that causes a
process abort with:

rd_kafka_enq_once_del_source_return: Assertion `eonce->refcnt > 0' failed

This affects all coordinator-targeted Admin API operations:
DescribeConsumerGroups, DeleteConsumerGroupOffsets,
ListConsumerGroupOffsets, and similar.

Root cause

When rd_kafka_admin_coord_request()'s inner request() call fails
(e.g., API not supported by broker, connection dropped), the error path
called rd_kafka_admin_common_worker_destroy() which freed the eonce
object. However, the caller (rd_kafka_coord_req_fsm) still holds a
reference to the eonce and passes it to rd_kafka_coord_req_fail(),
which enqueues a dummy error response with the now-freed eonce as opaque.

When rd_kafka_admin_coord_response_parse() later processes that response
and calls rd_kafka_enq_once_del_source_return(), it accesses freed memory,
triggering the assertion failure.

Fix

Remove the premature worker_destroy() call from the error path of
rd_kafka_admin_coord_request(). The error is returned to the caller,
which calls coord_req_fail() → coord_response_parse(). That function
already handles the error correctly: it calls del_source_return() to
retrieve the rko, sees the error, and calls worker_destroy() itself.

This matches the pattern already used by
rd_kafka_txn_send_TxnOffsetCommitRequest(), which has explicit comments
on its error paths documenting the same constraint:

/* Do not free the rko, it is passed as the reply_opaque
 * on the reply queue by coord_req_fsm() when we return
 * an error here. */

How to reproduce

The bug triggers under two conditions:

1. API version mismatch: broker doesn't support the requested API
   (e.g., OffsetDelete on broker < 2.4)
2. Connection disruption: broker restarts or connection drops during
   an Admin API fanout operation

Higher request frequency increases the likelihood of hitting the race.

Testing

This is a race condition on the error path of coordinator-targeted admin
requests. It requires either an API version mismatch or a connection failure
during the request send, making it difficult to reproduce deterministically
in a unit test. Happy to add a test if maintainers can suggest an approach
for reliably triggering the send failure.

Fixes #4605
Fixes #3663

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
✅ piochelepiotr
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}