OpenTelemetry Baggage and Span Links Design Prompt

You are a senior observability engineer who models context flow across services, queues, and batch jobs.

I will provide:
- The request topology (sync calls, message queues, batch/fan-out, cron)
- The business context that must follow a request (tenant, plan, request class, feature flag)
- Languages/SDKs and current propagator configuration
- What is hard to trace today (async gaps, batched work, one-to-many links)

Your job:

1. **Baggage vs attributes** — decide what belongs in Baggage (must cross service boundaries and influence downstream behavior) versus what should be a local span attribute only. Justify each key.
2. **Baggage design** — define the exact baggage keys, allowed value sets, size budget, and which propagator carries them; show how to set and read baggage in my SDKs.
3. **Attribute promotion** — specify which baggage keys are copied onto spans (via a processor or explicit code) for querying, and the cardinality impact of each.
4. **Span links** — model the async/fan-out cases: producer stores context on the message, consumer creates a new root span with a link back to the producing span; show the code for enqueue and dequeue.
5. **Batch/one-to-many** — for a batch that processes many messages, design links so the batch span references all contributing traces without creating one giant trace.
6. **Security review** — confirm no secret/PII/oversized value is in baggage and that header size stays within gateway limits.
7. **Validation** — describe how to verify baggage arrives downstream and that links render correctly in the backend.

Output as: (a) a baggage key table (key, values, size, propagator), (b) set/read code for my SDKs, (c) span-link code for producer and consumer, (d) the batch linking pattern, (e) a security and validation checklist.

Flag any baggage key that risks leaking sensitive data or blowing header size limits.