Check-in [2dfd42319f]

RFC 0009 §premerge, implemented. Nothing enters the DAG.

The helper

quarry-premerge --clone URL --branch-tip H --target-tip H (library: internal/premerge) clones over HTTP, opens the target tip, merges the branch tip into the working tree — zit's merge writes no check-in — and prints the prepared directory; a conflicted pair exits 2 with the files, a verdict rather than an error. It never commits, and it turns autosync off in the prepared checkout: the integration test commits in the tree on purpose and asserts the source ledger is unchanged — which is how we caught autosync pushing a test commit home through the clone's saved remote. Belt (settings) and braces (read-only credentials in production).

Pair-keyed verdicts

A premerge run's subject is pair:<branchTip>:<targetTip> — never a check-in, because the merge the accept later writes will hash differently. ci_run gained a pair column (migration for old stores); check.report accepts pair subjects, so an external CI can run the helper and report on the pair. A moved target changes the pair, so every stale verdict expires by construction — merge-queue freshness without a queue.

Per-branch mode

The protected-branches settings row gained a premerge checkbox (branch_required_checks.mode). In premerge mode the landing's checks panel and the accept gate read pair-keyed runs and pair-subject external checks only — a green tip run does not satisfy a premerge requirement (tested) — and the panel says which tree the checks are about.

Scope honesty

Engine-launched premerge runs (quarry starting them on landing events) arrive with the run-labels rung (dagnats#629); today the pair path is driven by workers/external CI via the helper + check.report. Verdict-tag carry-forward at accept and auto-accept-when-green are the next rung.