MongoDB connector v2.0.1 crash-loops on DDN cloud: tracing init panics with NoHttpClient (ndc-sdk v0.9.0 / opentelemetry-otlp 0.31 feature conflict)

### Component

Other connectors → `c/ddn-ndc-hub` (root cause is in `hasura/ndc-sdk-rs` v0.9.0, manifests in `hasura/ndc-mongodb` v2.0.1)

### What is the current behaviour?

Deploying `hasura/mongodb` v2.0.1 to DDN cloud fails — the connector container panics during startup and crash-loops, so the connector build never goes healthy:

```
thread 'main' (1) panicked at .../ndc-sdk-0.9.0/src/default_main.rs:228:6:
Unable to initialize tracing: NoHttpClient
Container called exit(101).
```

The same connector runs fine locally, and v1.8.4 works in both environments.

### What is the expected behaviour?

The connector starts and serves traffic on DDN cloud. A tracing-export problem should arguably degrade gracefully rather than panic the process.

### How to reproduce the issue?

1. `ddn connector init mydb --hub-connector hasura/mongodb:v2.0.1 -i` with any MongoDB source
2. `ddn supergraph build create` and deploy to a DDN cloud project
3. Connector build fails; runtime logs show the panic above

### Please provide any traces or logs that could help here.

```
2026-06-05T15:20:20.995495Z: thread 'main' (1) panicked at /nix/store/...-vendor-cargo-deps/.../ndc-sdk-0.9.0/src/default_main.rs:228:6:
2026-06-05T15:20:20.995516Z: Unable to initialize tracing: NoHttpClient
2026-06-05T15:20:21.582967111Z: Container called exit(101).
```

**Root cause** (verified against published sources):

1. ndc-sdk v0.9.0's workspace `Cargo.toml` enables `reqwest-client` on `opentelemetry-otlp = "0.31"` **without** `default-features = false`. opentelemetry-otlp 0.31.0's default features include `reqwest-blocking-client`, so both reqwest client features end up enabled (confirmed: ndc-mongodb v2.0.1's `Cargo.lock` pins opentelemetry-otlp 0.31.0).
2. In opentelemetry-otlp 0.31.0 (`src/exporter/http/mod.rs:152-193`), default HTTP client selection uses three mutually exclusive `#[cfg(all(...))]` blocks, each requiring the other client features to be off. With both reqwest features on, **all three blocks are excluded at compile time**, `http_client` stays `None`, and line 195 returns `ExporterBuildError::NoHttpClient`. (0.31.1 is byte-identical here.)
3. `init_tracing` in `crates/sdk/src/tracing.rs` only takes the `.with_http()` path when `OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf`; unset, it defaults to `.with_tonic()` (gRPC), which is unaffected. DDN cloud evidently sets `http/protobuf` — the panic proves the HTTP path was taken there — which is why this only reproduces on cloud deploys.
4. `default_main.rs:228` converts the error to a panic via `.expect("Unable to initialize tracing")`.

### Any possible solutions/workarounds you're aware of?

**Fix (in `hasura/ndc-sdk-rs`):** upgrade `opentelemetry-otlp` to **0.32.0**, which replaced the mutually exclusive cfg blocks with priority-based, feature-additive selection (see open-telemetry/opentelemetry-rust#2994 — the 0.32.0 source comments this fix directly). Minimal alternative on 0.31: add `default-features = false` to the dependency. Connectors (e.g. ndc-mongodb) then need a release built against the fixed SDK.

**Workarounds:** pin `hasura/mongodb:v1.8.4` (uses opentelemetry-otlp 0.15, unaffected). Forcing `OTEL_EXPORTER_OTLP_PROTOCOL=grpc` should bypass the broken path, but unverified whether DDN cloud allows overriding it.

### Keywords

NoHttpClient, ndc-mongodb, ndc-sdk, opentelemetry-otlp, tracing panic, connector deploy failure, exit 101, reqwest-blocking-client

Start in the ndc-sdk-rs workspace Cargo.toml and compare the opentelemetry-otlp feature configuration with the 0.32.0 fix. Read crates/sdk/src/tracing.rs and default_main.rs:228 to trace the HTTP exporter path and panic. Update the SDK dependency, rebuild the MongoDB connector, and verify that deployment starts healthy and serves traffic on DDN cloud.

Written by the indexing model from the issue text.