fix(otel): use async reqwest client so OTLP export works in goose serve mode

[dorien-koelemeijer]

Summary

Swaps the opentelemetry-otlp feature from reqwest-blocking-client to the async reqwest-client (one line in Cargo.toml). This fixes OTLP export panicking and silently dropping all telemetry when goosed runs in goose serve (ACP) mode.

The bug

The OTLP exporter wraps each export in a block_on fallback for when there's no ambient Tokio runtime (the BatchProcessor runs in a raw std::thread). The blocking reqwest client creates and drops its own nested runtime per request, and dropping a runtime inside block_on panics:
thread 'OpenTelemetry.Logs.BatchProcessor' panicked: Cannot drop a runtime in a context where blocking is not allowed.

The exporter thread dies ~1s in, then every log is dropped with AfterShutdown warnings. goosed agent is unaffected (exports run in the ambient axum runtime → .await path, no block_on), which is why production telemetry works today. Only goose serve hits the broken path.

The fix

Switch to the async reqwest-client. The block_on wrapper was designed for an async client (per its own comment) - the async client reuses the reactor the wrapper provides, so no nested runtime is created or dropped. otlp.rs unchanged.

Testing

• cargo test -p goose --features otel --lib otel::otlp → 54 passed; clippy/fmt clean.
• goose serve export: 0 panics / 0 AfterShutdown (was 1 panic + ~1,580 drops).
• goosed agent export: unchanged, no regression.

End-to-end via goose-internal (the real goose serve consumer)

goose-internal runs the backend as goose serve and exports security telemetry (prompt/command-injection scan findings) over OTLP - it was getting nothing downstream because of this panic. Verified the fix end-to-end:

1. Built goose from this branch and pointed goose-internal's dev app at it via GOOSE_BIN=.../target/debug/goose just dev.
2. Confirmed the spawned process: goose serve mode, OTLP logs-only export enabled, correct endpoint/service name.
3. Ran a uniquely-tagged tool call in the app (echo GOOSE_INTERNAL_TEST_RUN_100) and kept the app open ~60s so the batch processor flushed during the session.
4. In the goosed log for that PID: the security scan fired and the exporter stayed healthy - 0 panics, 0 AfterShutdown, no OTLP export errors (vs. an immediate panic + thousands of dropped records on the unfixed binary).
5. Queried the collector’s backing store for the unique marker → row present. The same query returned nothing before the fix.

Risk

Low — single-line feature swap that restores the async client the wrapper was built for; agent-mode path verified non-regressed.

[shellz-n-stuff]

Nice

[michaelneale]

huh neat fix for that.