[codeandsolder]

Upgrade sqlx-otel from the dormant SQLx-0.8-era 0.3 line to released 0.5.0 and enable it in live-search's otel feature.

Implementation:

• use released sqlx-otel 0.5, matching SQLx 0.9, OpenTelemetry 0.32, and Rust 1.94
• use Cargo-authored lockfile changes, removing the duplicate SQLx 0.8 / OTel 0.31 dependency subtree
• keep one physical SQLx pool: request-facing application queries wrap a clone of its handle in sqlx_otel::Pool<Postgres> when otel is enabled
• keep migrations, LISTEN/NOTIFY, readiness probes, and graceful shutdown on the raw PgPool; readiness deliberately bypasses instrumentation to avoid probe-span noise
• centralize raw-to-application-pool conversion so production and integration fixtures use the same path
• make the observability contract explicit: SQLx OpenTelemetry is traces-only for now; no OTel MeterProvider is installed, so sqlx-otel's optional runtime pool metrics are not enabled, and the Axum Prometheus layer remains a separate metrics pipeline
• update README and canonical SKILL.md to describe the active integration
• add a focused real-Postgres integration test using an in-memory OTel exporter; it verifies a database CLIENT span is emitted and is correctly parented beneath an active tracing-opentelemetry span
• run that parenting test in the existing E2E CI job

The normal deployment Dockerfile still builds the default ssr feature set; otel remains an explicitly optional deployment feature.

Query annotations/nicer semantic operation names are intentionally not part of this dependency/instrumentation activation change; the integration still exposes SQL text and can add application-specific annotations separately.

Draft until the updated CI matrix, including the runtime span-parenting test, is green.