Use build-time Version constant for OTel `service.version` attribute

Description

The policy-engine sources its OpenTelemetry service.version resource attribute from a config field, tracing.service_version, with a hard-coded fallback of "1.0.0" when empty. As a result, every span carries service.version=1.0.0 regardless of the binary actually deployed (currently 1.1.0). Tracing dashboards (Jaeger, Tempo, Grafana) cannot filter spans by gateway version.

The binary already knows its version. Both gateway-runtime/policy-engine/cmd/policy-engine/main.go and gateway-controller/pkg/version/version.go declare a Version variable that the Dockerfile overrides via -ldflags from the build's VERSION argument. The tracing code never reads it.

A configurable service_version field also lets an operator set a value that does not match the binary, which is a foot-gun with no legitimate use case.

Proposed change:

1. In gateway-runtime/policy-engine/internal/tracing/tracer.go, source service.version from the build-injected Version constant instead of cfg.TracingConfig.ServiceVersion.
2. Remove tracing.service_version from the policy-engine config schema (TracingConfig.ServiceVersion) and from any shipped config.toml / config-template.toml.
3. Apply the same change in the gateway-controller's tracing setup (gateway-controller/pkg/config/config.go has the equivalent TracingConfig.ServiceVersion field).

Acceptance criteria:

• Deploying gateway 1.1.0 produces spans with service.version=1.1.0 automatically, with no config required.
• tracing.service_version no longer appears as a config option in either binary.
• Spans from different gateway versions can be distinguished in tracing UIs.

Out of scope:

Tracing endpoint, batch settings, sampling rate, and other tracing config remain configurable.

Version

No response

Related Issue

No response