feat(spec,schemas): adopt the CloudEvents attributes EEP had skipped

[ucekmez]

Summary

PR 8 of a stacked series. Base is #99. Not for merge without review.

event.envelope.json defines eight eep_-prefixed extensions and uses none of the optional CloudEvents attributes that solve the same problems.

Attribute	What it does	Why its absence hurts
subject	which thing inside source changed	subscribers must parse data to decide whether they wanted the event — exactly the context bloat EEP claims to remove
dataschema	payload contract travels with the event	a subscriber cannot validate a payload it has not seen before; agents need out-of-band docs
dataref	Claim Check — send a reference, not the body	conspicuous in a project whose front-page demo is "2.2 KB instead of 46 KB"
traceparent / tracestate	W3C Trace Context across the delivery boundary	EEP is multi-hop by design and the causal chain broke at every publisher/subscriber boundary

grep -r traceparent returned zero matches repo-wide. docs/ops/observability.md says "Use OpenTelemetry for metrics and traces" — non-normative prose, no wire field.

What changed

• event.envelope.json gains all five, with a W3C Trace Context pattern constraining traceparent. Types regenerated.
• New normative §7.1 — when to set each; the rule that a dataref without data MUST be fetched; and the prohibition on sending data and a dataref that disagree. Claim-check retrieval is an ordinary Layer 1 request and stays subject to the entity's gates (§3.4), so it does not become a gate bypass.
• WebhookDispatcher mirrors trace context into HTTP headers per the CloudEvents Distributed Tracing extension. Only well-formed values are forwarded — a malformed traceparent is worse than none, because it silently roots the subscriber's spans under a trace that never existed.
• Conformance vectors for the standard attributes, a claim-check event, and a malformed traceparent.

Scope

• Spec / schema only
• TypeScript package(s)
• Python package(s)
• Tests / CI
• Docs / examples

Checklist

• I read CONTRIBUTING.md and CODE_OF_CONDUCT.md.
• Tests added or updated where appropriate.
• Breaking change? No. Every addition is optional; existing publishers stay conformant. additionalProperties was already true on the envelope, so publishers already emitting these attributes were passing validation without the schema describing them.
• Documentation updated for user-visible behavior.

Verification

Suite	Result
tests/	184 passed (was 172)
@eep-dev/middleware	126 passed (was 121)
compliance-cli --fixtures	22 vectors, 0 failed
tests/cross-impl/test_conformance_fixtures.py	24 passed
codegen-schema-types --check	no drift

Notes for reviewers

The attribute-naming problem is recorded, not fixed. CloudEvents v1.0.2 restricts context attribute names to lowercase ASCII letters and digits — the underscore is excluded — so eep_version, eep_subscription_id and the rest are not conformant CloudEvents extension names. Every attribute added here uses a compliant name, but the existing eight do not.

I added a note in §7 rather than renaming, because a rename is breaking and deserves its own decision. It is harmless in structured mode and becomes load-bearing in binary content mode, where attributes become ce--prefixed headers. That is the next PR in this series, so the question will need an answer there — I'd rather surface it than have it decided implicitly by whoever writes the binary-mode mapping.

dataref semantics are specified but not implemented in the middleware — there is no payload store to reference. The spec text and vectors are what an implementor needs; the reference stack does not need to grow a blob store to make the pattern usable.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.