Allow consumers to receive log events via callback (feature request)

Summary

The SDK has a well-developed tracing setup — env filter generation, file rotation, Sentry integration, log packs. The same listener-shaped pattern that the FFI uses for almost every other kind of outbound event would fit logging cleanly: a consumer-supplied callback that receives structured log events alongside everything the SDK is already doing with them.

Adding it would give consumers a choice — keep the current SDK writers exactly as they are now, route logs into a custom sink instead, or run both at once.

What's there now

The FFI exposes:

• init_platform(config, ...) — sets up file/stdout writers and (optionally) the Sentry layer
• log_event(file, line, level, target, message) — lets consumers push log events into the SDK's tracing system
• reload_tracing_file_writer(config) — runtime reconfiguration for file output

Consumers can write into the SDK's logger and reconfigure its file output, but there's no path to receive structured log events. Output is owned by the SDK's writers.

Why this matters

Even with the existing setup, all logs (SDK-internal and the app's own logs that get fed in via log_event) end up in the SDK's writer. There's no way for the consumer to direct that stream anywhere else without reading the resulting file back.

A callback would let consumers route the unified stream wherever makes sense — a platform logger, a custom log aggregator, a test harness, an in-app log viewer — without giving up anything the SDK is already doing.

The listener pattern would work well here: it's already the SDK's house style for outbound events.

Proposed direction

A LogEventListener-shaped API parallel to the listener pattern already used elsewhere:

• Each emitted log event is dispatched to a consumer-supplied callback as a structured value (level, target, subsystem, category, message, file/line, timestamp, optional fields).
• The SDK's existing writers stay in place untouched; the callback is purely additive. Consumers can opt in without giving up file logging, Sentry, or anything else.

Implementation could route through tracing_subscriber as a custom layer that fans out to the consumer callback alongside the existing layers. None of the current behavior needs to change.

Start at the FFI entry points init_platform, log_event, and reload_tracing_file_writer, then compare the listener pattern used elsewhere with the proposed tracing_subscriber layer. Done means consumers can receive structured log events through a callback while existing writers and Sentry behavior remain unchanged.