fix(runtime): put the fork path in the bucket id, not just in the counter

[maverox]

Numbering fork sequences per path, in #100, stopped a cascade in which one extra spawn early in a request renumbered every fork after it and re-addressed everything beneath them. That part was right and stands. What went with it was a property the per-correlation counter had been giving for free, because the bucket id was still composed from the sequence alone:

bucket_id = "{parent}::fork-{seq}"

Every path's sequence starts at one, so two different fork sites under the same parent both minted root::fork-1. Measured across that change:

before (8341ca6):  site_a = root::fork-1   site_b = root::fork-2
after  (on main):  site_a = root::fork-1   site_b = root::fork-1

What the collision costs

A bucket is the scorer's statement that a region of work is unordered. unordered_distinct_lineage excuses a value divergence between two events whose buckets differ, and reads a shared bucket as a claim that the two are ordered with respect to each other. So a collision stops a genuine race between two detached tasks from being excused, and it arrives as a divergence — the same class of false report per-path numbering exists to prevent, reached from the other direction. It is latent in hyperswitch today, where the two fork sites sit on different flows.

The change

Put the path in the id as well as in the counter. The sequence stays local to the callsite, which is what keeps a fork elsewhere in the request from renumbering this one; the id now also carries which callsite it came from, which is what keeps two callsites apart.

The key is stable_callsite_hash, the FNV-1a already used for callsite addresses: deterministic across runs and across toolchains, which a DefaultHasher is not, so a recording and its candidate compute the same value. task_id is composed the same way for consistency.

Nothing parses a bucket id. Checked workspace-wide: every ::fork- occurrence outside the composition site is either a .contains() or a test literal that needs only the marker. The one reader outside the layer is is_fork_region; its doc comment named the old shape and now says the shape belongs to the layer.

Verification

just verify exits 0 unpiped on 1.96.0 — 55 test blocks, zero failures. MSRV cargo +1.85.0 check -p deja-runtime -p deja-context --all-targets exits 0.

The new test fails on the unmodified parent, for the right reason, so this carries its own proof rather than an argument:

assertion `left != right` failed
  left: "root::fork-1"
 right: "root::fork-1"

mutation	new test	cascade test	eviction test
site key is a constant	FAILED	ok	ok
restored	ok	ok	ok

That mutation is the discriminating one: it breaks only the new test, so the test is about the path key specifically and not about forking in general.

Why #100 was green

Both tests written with #100 assert properties that change added — a fork elsewhere must not renumber this one, and counters are evicted when the owning span closes. Neither asserts the property it inherited: that two sibling forks are distinct. The lost guarantee was not in the deleted lines, so neither the diff nor the mutation matrix showed it — every mutation run there broke a property that had already been written down. Worth carrying forward when a keying or numbering scheme changes: the properties the old scheme guaranteed incidentally are the ones nothing asserts.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PYTPJrzSTR1CWbAjouucTs