Add PropagatingInMemory testkit backend

[kubukoz]

What

Adds PropagatingInMemory, a testkit EntryPoint/Span implementation that models trace context propagation, complementing the existing InMemory.

InMemory records a command log but gives every span an empty/inherited kernel and a None spanId, so it can't express parentage — you can't assert that a continued span is really a child of the span whose kernel was propagated to it. PropagatingInMemory:

• assigns each span a distinct id (via a Concurrent counter), exposed idiomatically through spanId and its kernel (under the X-Natchez-Span-Id header);
• resolves an explicit parentKernel (from Span.Options.parentKernel) over the enclosing span when creating a child — the semantic real backends implement;
• exposes the resolved parent as Span.parentId, and records each created span (Recorded(name, id, parentId)) queryable via EntryPoint#spans.

Why

Testing that instrumentation propagates trace context across boundaries (e.g. a cache loader that continues a span from a kernel handed to it) currently isn't possible with the shipped testkit — every InMemory span hands out the same kernel and no id. This backend makes those assertions straightforward while leaving InMemory completely untouched.

Notes / open questions

• New file, no changes to InMemory — all existing core-tests fixtures pass unchanged.
• PropagatingInMemorySuite demonstrates: distinct ids surfaced via spanId/kernel, child parented to enclosing span, explicit parentKernel winning over the enclosing span, and concurrent children each keeping their own parent with no id collision.
• Draft: only Scala 2.13/JVM was compiled locally; the source is written cross-friendly but JS/Native/2.12 are unverified. Naming (PropagatingInMemory, Recorded, spans) and whether this belongs as a sibling vs. an extension of InMemory are open to feedback.

🤖 Generated with Claude Code

[bpholt]

This looks pretty useful! I was about to start working on something similar (I stumbled across a bug in some application code and wanted to use the lineages InMemory.EntryPoint to assert on span propagation, but as you know, that doesn't work) but luckily I noticed this PR first.

whether this belongs as a sibling vs. an extension of InMemory are open to feedback

IMO this would be more useful as an extension or update to InMemory.EntryPoint instead of a separate backend. InMemory's lineage concept works pretty well for what it does; it just doesn't support propagation via continue/continueOrElseRoot. But with this design, I think I'd need to use both PropagatingInMemory and InMemory in separate tests (or write some kind of bridging EntryPoint that delegates to both of them) and then have separate assertions. It'd be nice if it were all collapsed into one.

I suppose the downside is that existing tests with lineages might be broken? I wonder who's using that to test continue/continueOrElseRoot without wanting propagation to be checked; they might think they have coverage already and be missing issues?

[bpholt]

I noticed there are no tests that use continue or continueOrElseRoot. It'd probably be a good idea to test propagation via those paths too.

[bpholt]

There's a comment on EntryPoint#continue that says "If the required headers are not present in kernel an exception will be raised in F." I wonder if SpanIdHeader is not present in kernel, this should raise instead of silently falling back to effectively a new root span?