Describe the bug

While reviewing OpenTelemetry tracing behavior across multiple ingress controllers, I noticed that Emissary differs from other Envoy-based ingress controllers in how it models ingress entry spans.

When OpenTelemetry tracing is enabled, Emissary creates CLIENT spans for incoming HTTP requests, whereas other ingress controllers create SERVER root spans for the same traffic.

To Reproduce

1. Deploy Emissary v4.0.0-rc.1 with OpenTelemetry tracing enabled:

apiVersion: getambassador.io/v3alpha1
kind: TracingService
metadata:
  name: otel-tracing
  namespace: emissary
spec:
  service: "otel-collector.opentelemetry.svc.cluster.local:4317"
  driver: opentelemetry
  config:
    service_name: emissary-ingress

2. Configure a backend service and Mapping
3. Send HTTP traffic through Emissary
4. Inspect exported OTLP traces

Observed: ingress entry span has span.kind = 3 (CLIENT)
Expected: ingress entry span has span.kind = 2 (SERVER)

Expected behavior

Ingress entry-point spans should be modeled as SERVER root spans, consistent with Envoy semantics and with other Envoy-based ingress controllers.

Versions

• Emissary: v4.0.0-rc.1
• Kubernetes: kind

Additional context
Comparison with other Envoy-based ingress controllers

• Contour: creates span.kind = 2 (SERVER)
• kgateway: creates span.kind = 2 (SERVER)
• Emissary: creates span.kind = 3 (CLIENT)

Possible cause
This appears to be related to the traffic direction configured for Envoy listeners when tracing is enabled:

python/ambassador/envoy/v3/v3listener.py#L572

self.traffic_direction = "OUTBOUND"

For ingress listeners, this likely should be "INBOUND" so that Envoy emits SERVER spans for incoming requests.