Span tracing data isn't passed to the C logging callback

Finding: CustomLayer discards all span data.

CustomLayer (scylla-rust-wrapper/src/logging.rs:129) implements only on_event. There is no on_new_span, on_record, on_enter or on_close, so no span ever reaches the C log callback.

Consequences

1. Everything the Rust driver records on RequestSpan — partition key, token, replicas, shard, request/result size, result rows, speculative execution count — is invisible to a C/C++ application, at any log level. The cpp-driver's CassLogMessage has no notion of spans, so exposing this needs a deliberate design decision (flatten span fields into the event message? emit synthetic events on span open/close?).
2. Worse, it is not merely invisible but actively costly: with CASS_LOG_TRACE set, trace_span!("Request", ...) becomes enabled, which makes session.rs:1826 take its branch and compute get_cluster_state() + get_token_endpoints_iter() + format every replica as "{ip}-shard{n}" into a span field — all of which CustomLayer then throws away.

Start with CustomLayer in scylla-rust-wrapper/src/logging.rs:129 and the RequestSpan setup at session.rs:1826, then compare the available data with the C/C++ CassLogMessage callback. Decide how span fields should be exposed and how to avoid computing data that the callback discards. Done means the chosen span behavior is documented and consistently reaches the C callback.