test(e2e): assert speculation-tree parity on the landing pipeline

[behinddwalls]

Summary

Why?

The tree-driven speculation stack (speculate rework, prioritize stage, path-driven build) claims exact behavioral parity with the previous naive pipeline. The e2e suite proved the black-box half (requests still land, timelines unchanged) but nothing verified the new persisted machinery: that the tree exists, holds exactly the parity chain path, and that exactly one build ran per batch.

What?

White-box e2e assertions on top of the existing flows (no new scenarios): the suite now constructs the batch, speculation-tree, and build mysql stores against the app DB like the other stores, with harness helpers to map a request to its batch and fetch its tree/builds. The happy-path landing test additionally asserts the landed batch's tree has exactly one path (Head = batch, Base = the batch's dependencies in order), reached passed with a stamped BuildID and a positive naive score, a version past the initial write, and that exactly one build exists whose speculation path matches and succeeded. The cancel test asserts no non-terminal build survives cancellation and, when the batch did reach Cancelled with a tree, that every path is cancelled (tolerating cancel-before-speculation leaving no tree). Comparisons normalize the nil-vs-empty-slice JSON artifact between batch.Dependencies and path.Base while keeping ordered-content equality.

Test Plan

✅ make gazelle && make fmt clean; ✅ make e2e-test — both e2e targets pass with the new assertions.

Stack

1. feat(speculate): write the speculation tree in shadow mode #353
2. feat(speculation): route builds through the tree via prioritize #365
3. feat(speculation): reconcile dead paths and finalize from the tree #371
4. feat(speculation): cancel batches through the tree via prioritize #379
5. feat(speculation): optimistic merge finalization behind a confirmed hand-off #380
6. @ test(e2e): assert speculation-tree parity on the landing pipeline #381
7. fix(orchestrator): re-trigger publishes need distinct message IDs #382