HYBIM-1011 Upgrade openai to 3.x.x(BLOCKED)

[ridhima-splunk]

Before PR changes trace
After trace

What was successfully removed: litellm as an explicit dependency — from handler.py, [project.optional-dependencies], and [tool.poetry.dependencies]. Token counts continue to work via LLMCallCompletedEvent on the crewai event bus.

What is still blocked: poetry lock cannot succeed because crewai (any version through 0.203.2 and 1.x) transitively depends on instructor, which requires openai <3.0.0. Poetry 2.x resolves all optional extras together so the conflict is
unavoidable in a single lockfile.

Root cause: instructor hasn't released support for openai 3.x yet. Until it does, openai 3.x and crewai cannot share a poetry.lock. This is an upstream ecosystem issue — nothing we can change in this repo today will resolve it.

[ridhima-cisco]

poetry.lock regeneration blocked by litellm conflict

litellm >=1.83.14,<2.0.0 (required by the crewai extra) hard-requires openai <3.0.0 in all versions up to and including 1.99.0rc1 (latest as of 2026-08-27). Poetry resolves all optional extras together, so openai >=3.0.0 and litellm cannot coexist in a single poetry.lock.

This means poetry lock fails until one of:

1. litellm ships a release with openai >=3.0.0 support (not yet available)
2. The crewai/litellm extra is moved to a separate Poetry dependency group decoupled from the main resolution

What was fixed in this PR:

• openai bumped to >=3.0.0,<4.0.0 in all four places in pyproject.toml
• openai-agents bumped to >=0.21.0,<1.0.0 (first version requiring openai 3.x)
• test_openai_agents.py: replaced respx + httpx.Response with httpx2.MockTransport + OpenAIProvider(openai_client=...) — needed because openai 3.x uses httpx2 internally and respx 0.22 cannot intercept httpx2 requests
• Removed explicit httpx2 dev dependency (installed transitively by openai 3.x)

CI failures are solely due to the stale poetry.lock — the lockfile cannot be regenerated until the litellm conflict is resolved upstream.