feat(runway): reject changes that disagree on provider

[behinddwalls]

Summary

Why?

The merger decides which provider a change came from by its URI scheme, and rejects a scheme it has no parser for. That part works, and it happens before any git command runs.

What it does not do is check that the changes in one request agree with each other. resolveChange determines the provider per URI and then discards it, so a request whose steps are addressed through different providers is resolved by different parsers and applied as though nothing were unusual. SubmitQueue already refuses that within a single change, but a Runway request carries one step per SubmitQueue request, so nothing covers the request as a whole.

What?

Keeps Provider on changeRef — the scheme the change was addressed through — rather than parsing it and throwing it away.

resolveAndValidate now compares every change against the first and rejects a request that mixes providers, naming both and the steps they came from. It already walked every URI to validate it, and it runs before the mutex and before any git command, so an incoherent request costs nothing and leaves the checkout untouched.

This cannot refuse a legitimate request: there is no way to address one merge through two providers, and the apply paths would otherwise have to reason about changes resolved by different parsers.

Also names the change, not just the commit, in the unavailable-commit error, so the reader is not sent looking for a deleted commit when the likelier cause is a change this remote was never going to serve.

Whether a change belongs to the repository this merger serves is deliberately not checked. The merger is already constrained to its checkout and remote by configuration, and a change it cannot fetch is refused on those grounds.

Test Plan

✅ bazel test //runway/... — all targets pass (git suite 70s)
✅ make lint, make check-tidy, make check-gazelle, make test

New cases: two steps using different providers, one change spanning two providers, and an unsupported provider — each asserted terminal and not a conflict. A multi-step multi-URI request through one provider is asserted to still succeed, guarding against over-rejecting.

The rejection cases run against a Merger whose git executable does not exist, so any git invocation would fail as an exec error. Getting ErrInvalidRequest back proves the request was refused before the merger reached for git.

Stack

1. feat(runway): dlq reconciler for merge topics #459
2. feat(runway): git-backed merger with REBASE #460
3. feat(runway): git merger SQUASH_REBASE and MERGE #461
4. feat(runway): git merger PROMOTE #462
5. feat(runway): wire the git merger into the server #463
6. @ feat(runway): reject changes that disagree on provider #476
7. docs: define the URI as the unit of change #477

[behinddwalls]

i think we can drop this, for now I was mostly concerned about merger's ability to fetch the changes using git for say github PRs...so if we put a constraint on it, it's enough

[behinddwalls]

Done — dropped Repo and the repository comparison, kept the provider one.

To be explicit about where that leaves things, since the two were doing different jobs:

• Fetching GitHub PRs — your original concern — is handled in feat(runway): git-backed merger with REBASE #460 and is unchanged: each referenced commit is fetched by SHA (falling back to refs/pull/<n>/head) and verified present before any step is applied.
• The merger is constrained to its checkout, remote and target by configuration. A change it cannot fetch is refused on those grounds, which is the constraint you're pointing at.
• What's left here is only that one request cannot mix providers. It costs nothing — resolveAndValidate already walks every URI — and it keeps the apply paths from having to reason about changes resolved by different parsers.

I also kept the error-message change: the unavailable-commit error now names the change rather than just the commit, so it doesn't read as a deleted commit when the real cause is a change this remote was never going to serve.

The PR title narrowed to match ("reject changes that disagree on provider"). Head is now b9c16551.