fix(cluster): avoid panicking when a change stream is dropped

[fmassot]

Summary

• create the DataFusion cluster change stream only when the endpoint is enabled
• treat a dropped receiver during initial cluster replay as normal cancellation
• add regression coverage for registering a dropped change-stream receiver

Root cause

The DataFusion setup eagerly created a cluster change stream before checking QW_ENABLE_DATAFUSION_ENDPOINT. When the endpoint was disabled, the receiver was dropped immediately. The asynchronous initial replay then sent to the closed receiver and panicked. Search-only nodes reproduced this reliably after discovering an already-ready peer.

Testing

• cargo test -p quickwit-cluster test_register_change_stream_subscriber_with_dropped_receiver --all-features
• cargo check -p quickwit-serve --all-features --tests
• cargo clippy --workspace --all-features --tests
• cargo +nightly fmt --all -- --check
• bash scripts/check_license_headers.sh
• started a primary and search-only node with DataFusion disabled; both became ready without a panic
• ran a REST search through the search-only node successfully