[BUG] Title: Dependency constraints in `pyproject.toml` are overly strict

### Description

I’m hitting repeated dependency-resolution failures because several constraints in `pyproject.toml` are much stricter than the broader Python AI ecosystem now expects.

Concrete examples:
- **`openai` is pinned to a very narrow window** (`openai>=1.83.0,<1.84.dev0`). This makes CrewAI incompatible with packages that require newer OpenAI SDKs (e.g. `langchain-openai>=1.0.3` requires `openai>=1.109.1,<3.0.0`, and tools/observability integrations like `openlit` require `openai>=1.92.0`).

### Steps to Reproduce

`uv add "crewai[tools]" "langchain-openai>=1.0.3"`

Resolver fails because CrewAI pins OpenAI SDK to `<1.84.dev0` while `langchain-openai` needs `>=1.109.1`.

### Expected behavior

CrewAI should remain installable alongside common ecosystem packages (LangChain integrations, LiteLLM proxy stacks, observability tools, transformers/sentence-transformers), unless CrewAI truly requires a breaking API change.

### Screenshots/Code snippets

- Package manager: `uv`

### Operating System

macOS Sonoma

### Python Version

3.12

### crewAI Version

1.9.2

### crewAI Tools Version

1.9.2

### Virtual Environment

Poetry

### Evidence

Error: Exit code 1
       × No solution found when resolving dependencies for split (markers:
       │ python_full_version >= '3.14'):
       ╰─▶ Because crewai==1.9.2 depends on openai>=1.83.0,<1.84.dev0 and your
           project depends on crewai[litellm]==1.9.2, we can conclude that your
           project depends on openai>=1.83.0,<1.84.dev0.
           And because your project depends on openai>=1.90.0, we can conclude that
           your project's requirements are unsatisfiable.

### Possible Solution

**Relax `openai` constraint**
   - If CrewAI is compatible with newer OpenAI SDKs: widen to something like:
     - `openai>=1.83.0,<3.0.0` (or `<2.0.0` if 2.x is truly incompatible)

### Additional context

Strict pins force users to fork or vendor CrewAI just to integrate with standard tooling. Relaxing constraints (plus a small compatibility test suite) would massively improve install success rates without sacrificing stability.

[]