Standard OTLP/HTTP trace receiver

[josedaniel-dev]

Step 5 of docs/roadmap.md.

• POST /v1/otlp/v1/traces: OTLP/HTTP, protobuf (the usual default) or JSON, gzip/deflate, ExportTraceServiceResponse with partialSuccess. Set OTEL_EXPORTER_OTLP_ENDPOINT=http://host:8100/v1/otlp; auth via OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer …. gRPC is out of scope.
• It translates OTLP spans into the existing manitos.telemetry.v1 envelope and reuses its ingestion (extracted as apply_envelope, route unchanged), so idempotency, upsert and the dashboard are shared. Trace id → UUID; span id → stable derived UUID, so a retry updates instead of duplicating.
• GenAI / OpenInference conventions map to span types (llm, tool, agent, embedding…), token counts and model; tool spans are named after the tool, so they feed the test-case checks and observer-regression.
• Spans of one trace may arrive in several batches: the trace keeps its full time range and a child links to a parent stored earlier. A rejected trace (e.g. owned by another project) leaves no receipt (savepoint) and is counted in rejectedSpans.
• Privacy: metadata-only by default. OBSERVATORY_OTLP_CAPTURE=metadata drops content-like attributes (prompt, completion, content, message, input, output, url, path, token, key…) before storage; full keeps them. The filter checks names, not values — documented as a safety net in docs/otlp.md.
• New dependency: opentelemetry-proto>=1.27,<2 (brings protobuf).

Tests: translation, privacy, protobuf+gzip, JSON, retries, multi-batch linking, error paths, project conflict. Backend 203 passed, ruff clean. Verified with a stock opentelemetry-sdk + opentelemetry-exporter-otlp-proto-http app: trace, spans, token counts and a tool span arrived; the prompt attribute did not.

No migration and no dashboard change.