Populate audit trace context from params._meta (traceparent)

[plusky]

Blocks #31 — the collector documentation describes correlating guard
records with client traces, which needs this field populated to be true.

The audit event schema already carries a trace field (TraceContext —
trace_id + span_id), but nothing ever populates it: every record is written
without one. That leaves the audit log correlatable only by timestamp and
session id when it is read next to a client's own traces.

MCP carries trace context in a request's params._meta (SEP-414), and clients
that are instrumented for distributed tracing already send it. Extracting it is
enough to join a guard record to the client operation that caused it.

Proposal

• Parse traceparent (and tracestate, if we keep it) out of params._meta
  on each request and put the ids into the record's existing trace field.
• Treat the value as untrusted input: validate the format, and record nothing
  rather than recording a malformed or oversized value.
• No change to the response path — this is record enrichment only, so
  responses stay byte-identical (I15).

Acceptance criteria

• A request carrying a well-formed traceparent produces a record whose
  trace ids match it.
• A request with no trace context, or a malformed one, produces a record
  with no trace field and is otherwise unchanged.
• Trace context never influences a guard decision or a response.

---

See also #34 §4(d) — 2026-07-28 makes SEP-414 documented convention and adds baggage alongside traceparent/tracestate; unlike traceparent it is not fixed-width, so it needs its own bound or a deliberate skip.