GetSignalsRequest as RootModel breaks the library's own inheritance pattern in consumers

[KonstantinMirin]

The salesagent project follows the documented pattern of inheriting from library types to add environment-based Pydantic config:

class GetSignalsRequest(LibraryGetSignalsRequest):
    model_config = ConfigDict(extra=get_pydantic_extra_mode())
    # extra="forbid" in dev/CI, extra="ignore" in production

In 3.6.0, GetSignalsRequest became RootModel[GetSignalsRequest1 | GetSignalsRequest2]. Pydantic hard-rejects model_config['extra'] on any RootModel subclass at class construction time:

PydanticUserError: `RootModel` does not support setting `model_config['extra']`

This means the inheritance pattern — which was designed and documented for this library — cannot be applied to GetSignalsRequest in 3.6.0. We had to fall back to a plain re-export (GetSignalsRequest = LibraryGetSignalsRequest), losing the environment-based strictness.

Root cause: oneOf in the JSON schema is translated by datamodel-code-generator to RootModel[A | B], which seals the class against model_config overrides.

What we'd need: Either a semantic type alias (like PricingOption in aliases.py) that exposes the union as a plain Python Union type rather than a RootModel wrapper, or restructure the JSON schema to express the signal_spec/signal_ids constraint as a single object with a Pydantic model_validator instead of oneOf.

The PricingOption alias pattern from a1c61e7 would solve this if applied to GetSignalsRequest:

# aliases.py
GetSignalsRequest = GetSignalsRequest1 | GetSignalsRequest2

Consumers could then isinstance(req, GetSignalsRequest1) or isinstance(req, GetSignalsRequest2) for branching, and subclass either variant if they need extra config.