fix(examples): reference stacks read delivery_url, the field the schema defines

[ucekmez]

Summary

PR 5 of a stacked series. Base is #96. Not for merge without review.

Found while checking field names for #96.

Both reference implementations read body.callback_url on subscribe:

callback_url: typeof body.callback_url === "string" ? body.callback_url : undefined,

schemas/v0.1/subscription.request.json defines delivery_url and has no callback_url property at all. So a conformant subscriber's delivery target was silently discarded — the subscription was created, returned 200, and could never receive a webhook.

callback_url is the stacks' own internal column name. It was never part of the request body. Both @eep-dev/middleware and eep-middleware read delivery_url correctly. Only the reference stacks — the code implementors are pointed at as the worked example — got it wrong.

Why it survived: the existing tests posted callback_url themselves and never asserted on the stored value. tests/cross-impl does send the correct delivery_url, but it exercises the gate publisher example, not these stacks.

What changed

• Read delivery_url, falling back to callback_url as a deprecated alias so existing demo scripts keep working.
• Echo delivery_url and created_at in the subscribe response, so the recorded target is assertable rather than write-only. This is what makes the regression tests meaningful — a test that can't observe the stored value is how this bug hid.
• Return 201 for a created subscription, matching §5.1.1 and both middleware packages. The stacks returned 200.
• Regression tests in both stacks: the wire field, the deprecated alias, the status code.

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? Behaviour change in example stacks only, no published package touched. Subscribe now returns 201 instead of 200; any consumer asserting 200 needs updating (both in-tree suites are updated here).
• Documentation updated for user-visible behavior.

Verification

Suite	Result
Node reference impl (vitest)	18 passed (was 16)
Python reference impl (pytest)	26 passed, 1 pre-existing failure (see below)

Two things maintainers should know

1. No CI job runs these suites. There is no test-reference-implementation job in .github/workflows/test.yml — the jobs cover every @eep-dev/* and eep-*-python package plus cross-impl, but not the reference stacks. That is precisely why this bug survived. The README describes this stack as what "contributors and CI use to exercise Layer 1 discovery, Layer 2 subscribe/stream, Layer 3 pulse and the gate endpoints against shared parity fixtures." CI does not.

2. python/tests/test_app.py::test_combined_bundle_content needs the local eep-gates, not the installed one.

I originally reported this as a TypeScript/Python parity defect. That was wrong — I'm correcting it here. Against the repo source, the Python reference suite is fully green:

27 passed — eep_api_python/app.py 164 stmts, 100% coverage

The failure I hit came from my virtualenv resolving eep_gates to a stale copy in site-packages that was missing the tier-resource filter in access_resolver.py. Both the repo source and the published eep-gates==0.1.0 wheel contain that filter — I checked the wheel directly. There is no parity defect and no published-package bug. Apologies for the noise.

What it does illustrate is point 1: because no CI job installs and runs these stacks, "the reference implementation passes" depends on whatever happens to be in a contributor's environment. The follow-up PR adds the missing jobs, pinned to the workspace sources.

[Copilot]

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