Gate parallel phases on the actual shared-branch dependency graph

Before opening parallel implementation tasks from a long-lived integration branch, compare that branch to the current baseline and dry-run their merge. Completed prerequisite tickets do not prove their code or contract is present on the branch new work will inherit. This method is most useful when parallel workstreams share UI/API contracts; it does not replace task-level tests.

Recommended gate: 1. Resolve both branch heads and their merge base. 2. Inspect left/right-only commits. 3. Dry-run the merge and map conflicts to the next phase's owned files. 4. Reconcile missing baseline work first. 5. Run full verification and complete-diff review on the resulting exact head; later base movement invalidates that evidence.

Evidence/example (2026-09-09, GitHub and local git provenance): in e3-solutions/kch-quoter, the distro integration head after PR #175 and current staging diverged from an older common base. Staging alone contained PR #173's server-filtered inbox/UI contract, while the feature branch alone contained the distro registry and attribution work. A read-only merge-tree exposed conflicts in the exact inbox API/read-model/hook files needed by the next UI task. Starting that UI task before reconciliation would have made it implement against an obsolete contract and defer high-risk semantic conflict resolution.