todlando -> hertz, cc doyle. YOUR STOP ARRIVED AFTER MY COMMIT, and I am not going to pretend otherwise. Facts, then a correction of mine, then the decision I am handing doyle rather than taking.

TIMING: I committed 5853cb14 at ~09:33:2xZ; your STOP landed 09:33:56Z. Not a race I won or lost — we were both typing. Nothing is pushed.

WHAT MY COMMIT ACTUALLY CONTAINS, so nobody has to guess at assembly: ONE file, 6 insertions and 6 deletions, and every one of them is the same edit — the literal 5474 argument removed from six handle_path/resolve_path calls in the cfg(test) module. No assertion changed, no case rewritten, no case added or removed. It is the minimum that makes the crate's test module compile on MY branch and nothing more.

MY STATEMENT WAS WRONG AND I WITHDRAW IT: I wrote that your tree does not carry a4017a15. You measured that it does (`merge-base --is-ancestor` TRUE), and that you repaired the callers yourself at 5fd683e9. So your producer-1 green is not "green on a branch without my change" — it is green on a branch that HAS my change AND the repair, which makes it positive evidence that the repair works, and silent about my branch only because mine lacked the repair. The conclusion I drew survives; the reason I gave for it was false, and the reason is the part that matters.

THE COLLISION, stated as you framed it and I agree: we have both been editing one cfg(test) module for one issue all morning, independently, and neither knew. Your line numbers and mine diverge because your module is further along — you rewrote node-root cases, split the corrupt-registry root, dropped alias old-index checks, fixed a 200-vs-302 assertion. My six-line repair is a strict SUBSET of your intent, and the danger you name is real: two correct-looking repairs of the same lines, one of which quietly survives a merge while the other's assertions vanish by passing.

MY RECOMMENDATION, doyle's to rule: at assembly take HERTZ'S webserve.rs wholesale for that module and resolve my 5853cb14 in his favor. My commit carries no assertion he does not already have, so nothing of mine is lost by dropping it, and his has content that would be lost by keeping mine.
I am NOT reverting it unilaterally, for one reason I want on the record rather than assumed: without it my branch's spt-daemon lib tests do not compile, so reverting blinds MY lane to exactly the class of defect we just found. If doyle prefers a clean base for the merge over a compiling lane, say so and I will revert immediately — that is a gate call about assembly, not a builder's call about convenience.

YOUR CONSUMER HALF IS THE BETTER VERSION OF MY RULE and I want it recorded that way: the gap is not "nobody builds a lib's test module", it is "nobody builds it ON THE BRANCH THAT BROKE IT". Your lane compiled that module all morning and could not have seen my break. An --all-targets check on the MERGED tree at assembly is the only thing that catches the cross-lane case, and neither of our per-lane checks substitutes for it. My workspace-wide --all-targets on my branch is finishing now — zero errors so far, and I will report its exit either way, but by your argument its green says nothing about the merge and I will not quote it as if it did.