Feat: Add the lineage demo — per-request lineage from the sidecar

authbridge/demos/README.md

@@ -23,6 +23,7 @@ more AuthBridge capabilities.
 | **[abctl Walkthrough](weather-agent/demo-with-abctl.md)** | Reference | Watch the AuthBridge plugin pipeline live with the `abctl` TUI | Tooling only |
 | **[IBAC](ibac/README.md)** | Intermediate | Intent-Based Access Control: LLM judge denies outbound HTTP that doesn't align with the user's recorded intent. Reproduces the email-poison / prompt-injection attack from `huang195/ibac`; chat with the agent through the rossoctl UI and see the exfiltration blocked, then `make show-result` for a pipeline-level forensic | UI + kubectl |
 | **[SPARC (finance)](finance-sparc/README.md)** | Intermediate | SPARC pre-tool reflection: the `sparc` plugin blocks a hallucinated/ungrounded tool argument (an invented transaction id) before it executes and transparently asks the user to clarify, then approves the corrected call. Complements IBAC — SPARC verifies argument grounding, IBAC verifies intent alignment | UI + kubectl |
+| **[Lineage](lineage/README.md)** | Intermediate | Per-request data lineage: enable the `lineage-telemetry` plugin and every HTTP exchange becomes two facts-only spans (`request` + `response`, paired by `lineage.exchange.id`) sent to **any** OTLP consumer. Ships a propagate-only OTel shim that makes the pairing correct under concurrency, and both attach paths — generate a Deployment, or patch one you do not own | kubectl + scripts |
 | **[CPEX Bridge (HR)](hr-cpex/README.md)** | Advanced | CPEX/APL declarative policy: one route chains a coarse APL predicate, an embedded Cedar PDP, RFC 8693 token exchange with a post-check, PII redaction and audit plugins. Same request, different data per caller (Bob sees an SSN, Eve gets it redacted). Self-contained: its own kind cluster + namespace, deployed via `make` rather than operator injection | [kubectl (make)](hr-cpex/README.md#quick-start) |
 
 ## Recommended Path

authbridge/demos/lineage/Dockerfile.otel-shim

@@ -0,0 +1,63 @@
+# GENERALIZED deploy-time propagation shim for ANY uninstrumented Python app.
+#
+# We DO NOT touch the app's source. We layer OpenTelemetry auto-instrumentation
+# ON TOP of the user's image so it PROPAGATES traceparent (extract on the inbound
+# ASGI/Starlette/FastAPI request, inject on the outbound httpx/requests/aiohttp
+# call) — nothing more. Spans are NOT exported (the Deployment passes
+# --traces_exporter none), so the shim adds nothing to your telemetry backend;
+# only the W3C traceparent header flows to the sidecar, which does the actual
+# capture.
+#
+# The instrumentors target LIBRARIES, not the app. `opentelemetry-instrument`
+# auto-activates whichever of these the app actually imports, so the SAME image
+# recipe works across every app whose server is ASGI/Starlette/FastAPI and whose
+# client is httpx / requests / aiohttp — the mainstream Python A2A/MCP stack.
+#
+# Build (parameterized — only BASE_IMAGE changes per app):
+#   podman build -f demos/lineage/Dockerfile.otel-shim \
+#     --build-arg BASE_IMAGE=docker.io/library/<app>:latest \
+#     -t <app>-otel:latest demos/lineage
+# or use demos/lineage/build-otel-shim.sh which also kind-loads it.
+#
+ARG BASE_IMAGE
+FROM ${BASE_IMAGE}
+
+# Where the app's virtualenv python lives. The common uv-built layout puts it at
+# /app/.venv; override for anything else.
+ARG VENV_PYTHON=/app/.venv/bin/python
+# The non-root UID the app runs as. 1001 is the usual agent-image default, but
+# platform images differ (999 is also common) — always confirm with `id` in the
+# base image rather than assuming.
+ARG APP_UID=1001
+
+USER root
+# Bring our own uv, pinned. Many app images ship uv on PATH, but an image that
+# builds its venv in a throwaway builder stage has NEITHER uv NOR pip in the
+# runtime layer (`uv venv` makes a pip-less venv). A copied static uv makes this
+# shim work on both without assuming the base carries a Python installer.
+# Overwriting an existing /usr/local/bin/uv is harmless.
+COPY --from=ghcr.io/astral-sh/uv:0.9.24 /uv /usr/local/bin/uv
+# One layer, all mainstream instrumentors. opentelemetry-distro pulls the SDK +
+# the `opentelemetry-instrument` launcher; the rest are the server/client
+# library instrumentors. starlette+asgi cover the a2a-sdk servers, fastapi+asgi
+# the FastAPI tools, and httpx / requests / aiohttp-client the three client
+# libraries those apps call out with.
+#
+# `-threading` is load-bearing for frameworks that run the LLM/tool call in a
+# worker thread (ag2/autogen use `loop.run_in_executor`; others use
+# ThreadPoolExecutor). OTEL context is contextvars-based and does NOT cross a
+# thread boundary by default, so without this the inbound trace is lost before
+# the outbound call and traceparent propagation silently breaks (the sidecar
+# then collapses all outbound onto one inbound under concurrency — 1/N). The
+# threading instrumentor copies the active context across `Thread.start` /
+# `ThreadPoolExecutor.submit`, restoring propagation.
+RUN uv pip install --python ${VENV_PYTHON} \
+      opentelemetry-distro \
+      opentelemetry-instrumentation-starlette \
+      opentelemetry-instrumentation-asgi \
+      opentelemetry-instrumentation-fastapi \
+      opentelemetry-instrumentation-httpx \
+      opentelemetry-instrumentation-requests \
+      opentelemetry-instrumentation-aiohttp-client \
+      opentelemetry-instrumentation-threading
+USER ${APP_UID}