feat(sidecar): OpenTelemetry spans + structured audit log + Jaeger compose

[VibhorGautam]

what

adds OpenTelemetry tracing and structured audit logging to the Go sidecar without changing the Stage interface or the wire format

each pipeline run gets a root span, 1 child span per stage and an opa.evaluate span. audit records carry decision metadata, signal names, provenance, session id, policy version, trace ids, block stage and duration. raw payload and canonical text aren't copied into telemetry

the compose profile starts the sidecar, a pinned OTel collector and Jaeger at http://localhost:16686

behavior

telemetry uses the runtime telemetry: config block. an empty endpoint installs a noop tracer. audit writes use a bounded queue, drop instead of blocking when full and drain during shutdown

bad magic, bad protocol version, bad HMAC, replayed nonces and signed invalid JSON are recorded as transport blocks. signal category strings from signed SDK requests pass through to OPA and audit, so SDK scanners must keep category names fixed and free of user content

hardening

the Aug 29 rebase also fixes concurrent Close callers reading the audit error before the drain finished, closes accepted connections before waiting for handlers, bounds tracer and audit shutdown, keeps audit failures fail-open, creates audit files with 0600 permissions and new parent directories with 0700, and fixes the compose path with a real sidecar image and required HMAC environment value

local cost

5-run medians with -benchtime=2s -count=5 -cpu=1:

config	ns/op	B/op	allocs/op
no telemetry	3,837	1,776	29
audit only	4,153	2,025	30
sampled tracer plus audit	6,207	5,745	44

these measure in-process span recording and audit queueing on the benchmark payload, not collector or network cost

testing

all 4 GitHub jobs are green after the rebase: Go, Python, ubuntu integration and windows integration

locally, the full Go race suite, go vet ./..., 114 Python tests, 102 OPA tests, the uncached integration suite, Windows compilation, YAML parsing and diff checks pass

Docker isn't installed locally, so the compose YAML was parsed but the image wasn't built here

scope

no metrics and no SDK frame change. Pipeline.RunContext can join a caller context, but v1 doesn't carry traceparent over IPC yet

[VibhorGautam]

quick follow-up while poking at the phase 02 docs for context on the otel span naming in this pr

one thing worth flagging for phase 3: docs/pipeline.md signal table lists hmac_invalid: 1.0 # always hard block, but sidecar/internal/pipeline/aggregate.go computes score = maxSignalWeight * provenanceWeight in AggregateStage.Run and always returns hardBlock=false. so if phase 3's opa path emits hmac_invalid for a memory-provenance payload (trust weight 0.6), the score ends up 1.0 × 0.6 = 0.6, which is sanitise under the default 0.85 block threshold, not block. since memory is exactly where hmac_invalid is supposed to be strict (tampered stored state), either it needs a validate-style hardBlock return before aggregate runs, or the "always hard block" note should say it's provenance-weighted like every other signal

not blocking for this otel pr, just flagging since i was in those files already. happy to split it out as a separate issue if useful