feat(runway): resolve merge targets per queue and provision their checkouts

[behinddwalls]

Summary

Why?

Three things stopped Runway from performing a real merge. It resolved one merger for the whole process, so a deployment could serve only one repository. Nothing created the checkout the git merger requires, which it declares must already exist. And the container had no git binary, while the merger demanded three absolute runtime paths — so enabling it failed at startup with git runtime executable is required rather than working.

What?

Merge targets come from MERGE_CONFIG_PATH, a YAML file with a defaults block and per-queue overrides. Each git target is provisioned at startup — repository initialised, remote configured, credential written, target branch checked out — idempotently, so a restart against a persisted volume costs nothing and a rotated token takes effect. The existing MERGE_* environment variables still configure a single target when no file is given.

Two queues naming one checkout resolve to the same merger instance, which is what serializes them: a git merger locks the working tree it owns, and two instances over one tree would reset it out from under each other mid-merge. That instance is built from whichever queue is reached first, so queues sharing a checkout have to agree on every field it is built from — not merely on the target. Any disagreement is rejected at startup, naming the field, because the alternative is a queue that asked for SQUASH_REBASE quietly merging with REBASE and reporting nothing. The comparison is structural rather than a list of fields to remember, so a field added to the merger later is covered on its own.

The credential never enters the remote URL. The merger folds git's stderr into the errors it returns, so a URL-embedded token would be reprinted into logs and dead-letter payloads by any failed fetch. It is written as an HTTP Authorization header into a 0600 config fragment the repository includes — which keeps it off the command line too. SSH needs no code at all: the merger already passes SSH_AUTH_SOCK and GIT_SSH_COMMAND through its scrubbed environment.

The git runtime is derived from the installed git when unset — executable from PATH, exec path from git --exec-path, templates from the matching install prefix — so the pinning safeguard stops being a boot-time trap. git is installed in the image.

Test Plan

✅ bazel test //service/runway/server:go_default_test — provisioning runs against real git (pinned, as the merger does): clone into an empty directory, idempotent re-run, drifted remote URL corrected, non-default target branch, credential written 0600 and absent from the remote URL, stale fragment removed, unset token rejected, and git-runtime derivation with and without the environment overrides.

✅ Sharing a checkout is now judged on the whole merger configuration, not just the target: two queues that agree everywhere still share one instance, two that disagree in defaultStrategy, updateHeadBranch, checkStaleness, maxPushAttempts, the committer identity or the refspecs are rejected at load, and a queue spelling a default explicitly still counts as agreeing.

[mnoah1]

Approving - comment below seems like an edge case we may want to consider.