ci(nightly): fail source_ref runs when the stack is missing patches from main

Context

A source_ref dispatch (#91) promotes a maintainer-resolved patch stack through the verified pipeline. The promotion's lease and moved-main check guard against main moving during the run, but nothing verifies the provided stack already contained everything on main when it was cut.

This bit us on 2026-08-11: the conflict resolution was cut before #87/#90/#91/#92 merged, and promoting it silently rolled main's workflow files back to the pre-merge state. #93 restored the dropped commits by cherry-pick. Until this guard exists, the operational rule is: refresh the resolution from current main immediately before dispatching.

Proposal

In prepare, when source_ref is set, compare patch-ids: every commit reachable from main but not from upstream must have a patch-id-equivalent commit in the candidate (git cherry / git patch-id machinery). If any are missing, fail the run loudly, listing the missing commits, before anything is verified or promoted.

Patch-id equivalence is imperfect — a resolution that legitimately reshapes a patch (conflict resolution changed its hunks) will look "missing". The check should therefore report clearly rather than guess, and may need an explicit override input (or acceptance that reshaped patches produce false positives the maintainer confirms by re-dispatching with an override). Design for loud-and-clear over clever.

Acceptance sketch

A source_ref stack cut from a stale main fails prepare with the dropped commits listed by subject.
A fresh resolution (all main patches present, possibly reshaped by conflict resolution) can still be promoted, via whatever override/confirmation shape review settles on.
Normal scheduled runs (no source_ref) are unaffected.