[BUG] opentelemetry ~=1.42.0 pins transitively cap protobuf<7.0, blocking co-installation

### Description

`crewai` pins all three OpenTelemetry packages to a single minor with `~=1.42.0`:

```
opentelemetry-api~=1.42.0
opentelemetry-sdk~=1.42.0
opentelemetry-exporter-otlp-proto-http~=1.42.0
```

Because `opentelemetry-exporter-otlp-proto-http==1.42.0` in turn requires `opentelemetry-proto==1.42.0` (an exact `==`, not a range), this transitively pins the entire OTel proto stack to exactly 1.42.0 — and `opentelemetry-proto` 1.42.0 is the last release that caps `protobuf<7.0`. 1.43.0 raised it to `<8.0` on 2026-06-24.

The effect is that **`crewai` is currently uninstallable alongside any package requiring protobuf 7.x**, even though the OTel constraint that causes it was lifted upstream two and a half months ago.

This is the same class of report as #4511 (closed), where the pin was `~=1.34` and was bumped to unblock a user. The bump resolved that instance, but the pin shape stayed the same, so the conflict recurs against a new set of packages each time the minor moves. This issue is about the shape rather than the number.

### Steps to Reproduce

```
$ uv pip compile <(printf 'crewai>=1.15.3\nprotobuf>=7.36.1,<8\n')
```

### Expected behavior

Resolves. Currently:

```
we can conclude that crewai>=1.15.3 depends on protobuf>=5.0,<7.0.
And because you require crewai>=1.15.3 and protobuf>=7.36.1,
we can conclude that your requirements are unsatisfiable.
```

Also unsatisfiable with `--prerelease=allow` against `1.15.20.dev20260905`.

One note for anyone reproducing this: leaving `crewai` unconstrained **appears** to succeed, because the resolver backtracks to `crewai==1.6.1` — nine minor versions back, predating the pin. The `>=1.15.3` floor is what keeps the failure visible.

### Suggested fix

Widen the three pins from `~=1.42.0` to a range, e.g. `>=1.42,<2`. Verified that this resolves against protobuf 7.x with no other change:

```
$ uv pip compile <(printf 'opentelemetry-api>=1.42,<2\nopentelemetry-sdk>=1.42,<2\nopentelemetry-exporter-otlp-proto-http>=1.42,<2\nprotobuf>=7.36.1,<8\n')
opentelemetry-api==1.44.0
opentelemetry-sdk==1.44.0
opentelemetry-exporter-otlp-proto-http==1.44.0
opentelemetry-proto==1.44.0
protobuf==7.36.1
```

OTel releases its core packages in lockstep, so a shared `>=1.42,<2` keeps them mutually consistent while letting the proto cap fix through. If the tight pin is deliberate — guarding against a known break in a later minor — that would be useful to state in a comment next to it, since from the outside it reads as incidental and it is currently load-bearing for downstream resolvability.

### Context

Reported from [`zer07labs/seam-sdk`](https://github.com/zer07labs/seam-sdk), whose generated protobuf stubs require a protobuf 7.x runtime (the gencode runtime-version check rejects an older runtime than the gencode). We are not asking for a change on our account — we have a documented two-environment arrangement and have closed our own tracking issue accordingly. Filing because the constraint looks unintended and affects more than us.

### Operating System

macOS 15 (also reproduces on Linux CI)

### Python Version

3.12

### crewAI Version

1.15.20

### Virtual Environment

uv

[]