HTTP client internal spans are exported as their own root traces

[adityak74]

Found in the telemetry UAT (docs/uat/UAT-telemetry.md, finding I2).

With --features otel, one agent run produces the expected connected trace rooted at agent_run, plus two extra single-span traces named encode_headers and parse_headers. Those come from the HTTP client's own instrumentation, not from zorp.

Observed against the example's Jaeger stack:

traceID 247ec537  spans=[agent_run, agent_step x2, model_complete x2, tool_execute]  roots=[agent_run]
traceID cada62da  spans=[encode_headers]  roots=[encode_headers]
traceID 3a5822b7  spans=[parse_headers]   roots=[parse_headers]

Not an error, and it does not affect correctness. It does make the Jaeger trace list noisy, and on a busy service it makes finding the real trace harder.

What to do: filter the HTTP client's spans out of the exported layer, most likely with a tracing_subscriber filter in the otel setup in zorp-agent/src/main.rs (mod otel_init). Keeping them at a lower level, or excluding that target, are both reasonable. Include a note in examples/telemetry/README.md if the behavior becomes configurable.

Verifying: docker compose up -d in examples/telemetry, run any task with OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318, then check curl -s 'http://localhost:16686/api/traces?service=zorp-agent' | jq '.data[].spans[].operationName'. You want one trace per run.