Bump OpenTelemetry off the ^0.205.0 line: upstream already dropped protobufjs, and it unblocks js-genai#1883

Follow-up to #797. This started as "file an upstream issue asking OpenTelemetry to move to protobufjs 8" and turned out to need no upstream work at all — **OTel already did it, then removed protobufjs entirely.** We're pinned to a range that can't reach either change.

## What upstream did

| `@opentelemetry/otlp-transformer` | `protobufjs` |
|---|---|
| 0.205.0 ← **what we resolve to** | `^7.3.0` |
| 0.206.0 | `^7.3.0` |
| 0.210.0 | `8.0.0` |
| 0.215.0 | `^8.0.1` |
| 0.220.0, 0.221.0 | **none** |

`core/package.json` pins the OTLP packages at `^0.205.0`. For a `0.x` version npm treats `^0.205.0` as `>=0.205.0 <0.206.0`, so we are held on the one line that still carries protobufjs 7.

## Why it matters beyond the bytes

`@google/genai` and `@opentelemetry/otlp-transformer` are currently the only two protobufjs consumers in the production tree, and they're the reason js-genai#1883 (bump genai to protobufjs `^8.4.0`) is currently a **regression** for us: with otel on `^7.3.0` and genai on `^8`, npm installs both majors side by side.

Bumping OTel removes the conflict and flips that issue from a cost to a win:

| scenario | tree | pkgs | protobufjs |
|---|---:|---:|---|
| today | 112.2 MB | 171 | one copy, v7 (otel + genai) |
| otel bumped | 101.6 MB | 204 | one copy, v7 (genai only) |
| otel bumped **+** js-genai#1883 | **99.6 MB** | **193** | one copy, v8; all 9 `@protobufjs/*` helpers gone |

So the ordering is: **bump OTel first, then js-genai#1883 becomes adoptable** and is worth −2.0 MB / −11 packages instead of +3.8 MB.

## The catch: package count goes up

This is not a clean win and shouldn't be treated as one.

```
today: 112.2 MB 171 pkgs
otel bumped: 101.6 MB 204 pkgs (-10.6 MB, +33 pkgs)
```

Newer OTel is more finely split, so we trade ~33 packages for ~10.6 MB. Given #626, #784 and #785 have all been optimising **package count**, that's a direct tension and needs a call on which axis matters more — or whether the OTLP exporters should move behind optional peers anyway (the "OpenTelemetry block" item in #797), which would make the question moot for most consumers.

I haven't evaluated the API delta. Going from `0.205.0` → `0.221.0` and `sdk-*` `2.1.x` → `2.10.x` is a real jump and `core/src/telemetry/{setup,google_cloud}.ts` would need checking, along with the two `@google-cloud/opentelemetry-cloud-*-exporter` optional peers which have their own OTel range constraints.

## Suggested sequence

1. Assess the OTel API delta for `core/src/telemetry/*` and the two GCP exporter peers.
2. Decide the package-count-vs-bytes tradeoff, ideally alongside the optional-peer question from #797.
3. If we bump: adopt js-genai#1883 once it lands, and drop the ⚠️ warning on it in #797.

## Related

- #797 — tracking issue; this resolves one of its future-work items
- js-genai#1883 — blocked on this to be worth adopting
- grpc/grpc-node#3067 — the *other* protobufjs `^7` holdout, an open PR. Not in our production tree (it arrives via the `@google-cloud/opentelemetry-cloud-trace-exporter` optional peer and `@grpc/grpc-js`), so it doesn't gate anything here, but it's the same migration. Added downstream measurements there.