### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

### Actual behavior

OTel v2 includes `gen_ai.request.model` in the default `BAGGAGE_PROMOTED_KEYS`. `seed_request_identity()` then stamps that Baggage onto the FastAPI SERVER span and the Baggage processor copies it to DB, Redis, auth, guardrail, and other child spans.

Those spans are not generative AI operations, but they carry a canonical `gen_ai.*` model attribute. GenAI-aware backends can therefore classify the HTTP request, database, or service span as an LLM generation. With the Langfuse mapper this produces multiple apparent generations for one provider call and inflates/noises the observation hierarchy; the actual `LLM_CALL` span is the only span that should be a generation.

### Expected behavior

Canonical `gen_ai.request.model` should only be present on real GenAI operation spans. If the requested model needs to be propagated for correlation, it should use a LiteLLM vendor attribute such as `litellm.request.model` on non-LLM spans, or the vendor mapper should explicitly mark non-LLM roles as spans.

This must preserve user/team cor…