[Story]: Export lightbridge-authz telemetry to the existing Alloy OTLP receiver

## User Story

**As** whoever is on call for `auth.ai.camer.digital`,
**I want** `lightbridge-authz`'s traces and metrics to reach the observability stack,
**so that** auth failures can be seen in Grafana rather than reconstructed from `kubectl logs`.

## Source of truth (links)

Parent epic #638. Motivating incident: #623, a 3h32m fresh-login outage nothing detected.

## Context

`lightbridge-authz` is instrumented with OpenTelemetry already (`lightbridge_authz_core::tracing`, OTLP → Jaeger in local compose). In prod it exports nowhere: there is no collector for it, and it is the only major service without one.

**Use the existing Alloy DaemonSet — not a dedicated OTel collector.** Decision by the repo owner. `governance-ai-cli`, `copilot` and `keycloak` each run their own collector; that pattern is explicitly *not* being copied.

Alloy already does the work. From the live `observability/alloy` ConfigMap:

```alloy
otelcol.receiver.otlp "default" {
grpc { endpoint = "0.0.0.0:4317" }
http { endpoint = "0.0.0.0:4318" }
output {
traces = [otelcol.exporter.otlp.tempo.input]
logs = [otelcol.exporter.loki.default.input]
metrics = [otelcol.exporter.prometheus.default.input]
}
}
```

So this is a **configuration change, not a deployment**: point the exporter at Alloy and the fan-out to Tempo/Loki/Mimir already exists.

## Acceptance Criteria

- [ ] `api`, `opa`, `idp` and `budget` export OTLP to the Alloy DaemonSet endpoint, configured in `ai-helm-values` (not hardcoded).
- [ ] Traces for a login appear in **Tempo**, queryable by trace ID.
- [ ] Metrics appear in **Mimir**, labelled well enough to distinguish the four components.
- [ ] Reaching Alloy from the `converse` namespace is **verified**, not assumed — the epic flags this as an unconfirmed assumption. If a NetworkPolicy or the DaemonSet's node-local addressing blocks it, that finding is the story's output and the approach gets revisited rather than forced.
- [ ] `lightbridge-authz` logs are confirmed present in Loki with the labels a dashboard can filter on (`namespace`, `pod`, `container`), by running a real LogQL query and pasting the result.
- [ ] No new collector Deployment/DaemonSet is added.

## Out of Scope

Dashboards (story 2) and alerts (story 3). New instrumentation in Rust — this story ships what is already emitted.

## Test Plan / Verification evidence

Perform a real login against staging or prod, then produce:
1. its trace in Tempo,
2. a LogQL query returning that request's log lines,
3. `kubectl` output showing no new collector workload.

## AI Usage Declaration

AI (Claude Opus 5, Claude Code) surveyed the deployed stack and drafted this story.

- [x] Alloy's OTLP receiver was read from the live ConfigMap, not assumed from documentation — which is what reduces this story from "deploy a collector" to "point an exporter".
- [x] The reachability assumption is stated as unverified rather than presented as fact.

## Human verification completed

- [ ] Owner confirms Alloy-only and the config-not-code placement.