feat(runway): classify invalid merge requests as terminal

[behinddwalls]

Summary

Why?

Runway is stateless and the sole responder on the client's correlation id: SubmitQueue records the in-flight work before publishing and waits for exactly one MergeResult echoing that id. A request that resolves to neither a success nor a failure leaves the client waiting forever.

Today the controllers treat exactly one error as a nameable outcome — merger.ErrConflict — and nack everything else for retry. But some requests are unusable as written: an unknown or unsupported merge strategy, a malformed change URI, an invalid strategy composition. Retrying those can never succeed. Nacking them burns the retry budget and then dead-letters, which — with nothing draining the dead-letter topics — is precisely the silent hang described above.

What?

Adds a second terminal sentinel to the merger contract, merger.ErrInvalidRequest, for requests that can never be applied as written, and merger.IsTerminal as the single classification point over both sentinels.

Switches both the merge and mergeconflictcheck controllers from an errors.Is(err, merger.ErrConflict) test to merger.IsTerminal(err), so an invalid request now publishes a FAILEDMergeResult and acks instead of nacking. The two cases stay distinguishable in observability: invalid requests increment an invalid_requests counter and log the underlying error, conflicts keep the existing merge_conflicts counter.

No implementation returns the new sentinel yet — the git-backed merger later in this stack is its first producer. This lands the contract and the controller behavior first so that change is only about merge mechanics.

Also corrects the Runway README, which still claimed the controllers merely deserialize and log the request.

Test Plan

✅ bazel test //runway/... — 4/4 pass, including new TestProcess_InvalidRequest cases on both controllers asserting a FAILED result is published and the delivery is acked
✅ make gazelle, make fmt