[FEATURE] `--output otel` phase 2 and 3: OTLP/HTTP push exporter and backend recipes

Inizia leggendo il design della fase 1 in #738 e l’implementazione esistente di Output Modes documentata in questa issue. Traccia quindi la generazione attuale dei record OTLP/JSON e pianifica l’exporter in base alle variabili d’ambiente elencate, al batching per statement, ai retry e allo scenario del robot OTLP simulato. Il lavoro è completato quando entrambe le fasi dell’exporter sono coperte, la documentazione di global-flags e Output Modes è aggiornata e sono documentate le ricette per ClickHouse, Datadog e CI pianificata.

Summary

Follow-up to #738, which shipped phase 1 (--output otel as a general output format, one OTLP/JSON LogsData per row plus a completion record per statement) in #754 and is documented under Output Modes. This issue carries the two remaining phases from that design.

Phase 2: OTLP/HTTP push exporter

Push the records straight to an OTLP-capable backend instead of (or as well as) writing the file, driven by the standard environment variables so no new flags are needed:

• OTEL_EXPORTER_OTLP_LOGS_ENDPOINT (falling back to OTEL_EXPORTER_OTLP_ENDPOINT + /v1/logs)
• OTEL_EXPORTER_OTLP_HEADERS (for example a Datadog API key or ClickStack ingestion token)

The LogsData emitted today is byte for byte the body of POST /v1/logs, so this is an HTTP client plus batching per statement (chunked for large result sets), no new dependency. Targets ClickStack's OTLP intake and Datadog's OTLP endpoint directly, and any OpenTelemetry Collector otlp receiver.

• Exporter behind the env vars above; batch per statement, chunked for large results; retry with backoff on 429 / 5xx
• Robot scenario against a mocked OTLP endpoint asserting the request body, headers and batching
• global-flags / Output Modes docs updated

Phase 3: backend recipes

A docs page with the joint use cases end to end:

• ClickHouse: materialized view from otel_logs into a typed inventory table keyed by (snapshot_id, identity); latest state per resource (argMax by timestamp); drift between two snapshots (join on identity, fingerprint inequality, anti-joins for appeared and disappeared); entitlement history (principal, role, first seen, last seen)
• Datadog: resource attribute mapping and the equivalent log queries
• A scheduled CI example (TRACEPARENT, OTEL_RESOURCE_ATTRIBUTES stamping deployment.environment and a job name)

Design already settled in #738

Per-row grain; statement start time as the snapshot instant on every record; stackql.snapshot.id, stackql.query.hash and stackql.row.fingerprint as the correlation keys; no identity heuristics (the backend chooses the key); nested columns as JSON strings in attributes with the full document in the body. The attribute schema is pinned at scope github.com/stackql/stackql/internal/stackql/output version 1.0.0.