## Description

The OpenTelemetry integration creates `raw_gen_ai_request` after its `litellm_request` parent has already ended.

The exported timestamps and parent ID look correctly nested because both spans are created with explicit historical `start_time` / `end_time` values. However, the actual processor lifecycle is:

1. `litellm_request.on_start` 2. `litellm_request.on_end` 3. `raw_gen_ai_request.on_start` 4. `raw_gen_ai_request.on_end`

Relevant code:

- `_start_primary_span()` ends `litellm_request` before returning it: https://github.com/BerriAI/litellm/blob/main/litellm/integrations/opentelemetry.py#L1229-L1234 - `_maybe_log_raw_request()` subsequently uses that ended span as the parent: https://github.com/BerriAI/litellm/blob/main/litellm/integrations/opentelemetry.py#L1253-L1262

This causes processors that track active parents to treat `raw_gen_ai_request` as a new root. For example, Langfuse marks these raw spans as application roots even though their persisted parent is `litellm_request`.

Observed with Google ADK using the LiteLLM SDK with a `litellm_proxy/...` model.

## Expected lifecycle

```text litellm_request.on_start raw_gen_ai_request.on_start raw_gen_ai…