feat(gateway): land and status subcommands for the client

[behinddwalls]

Summary

Why?

The gateway client only knew how to ping. Submitting a change meant hand-assembling protobuf with grpcurl, including a 40-character commit SHA copied out of a pull request — which is both tedious and easy to get subtly wrong.

What?

ping | land | status subcommands. land takes repeated -uri flags, whose order is significant: several changes in one request are a stack, applied in the order given.

-pr <url> resolves a pull request's head commit and mints the change URI, so nobody types a SHA. It dispatches on the change URL the same way the merger and the change provider dispatch on the URI scheme, rather than assuming one provider; GitHub is implemented, and adding another is a case beside it. Reading a public repository needs no token, and a 404 without one says so rather than reporting the pull request as missing.

Test Plan

✅ go build ./service/submitqueue/gateway/client and go vet.

✅ Manually: land -queue q reports the missing-change error; land -pr https://github.com/uber/cadence/pull/1 resolved against the live GitHub API and printed github://github.com/uber/cadence/pull/1/65c322d4... before failing to dial a gateway, which is the expected end of that path with no stack running.

Stack

1. feat(runway): move a change's head branch to the commit it landed as #542
2. feat(runway): resolve merge targets per queue and provision their checkouts #544
3. feat(orchestrator): build extension profiles from configuration #545
4. test(e2e): hermetic end-to-end coverage of a real git merge #546
5. @ feat(gateway): land and status subcommands for the client #547
6. docs(submitqueue): provider example configuration and landing runbook #548