refactor(platform)!: move CI clients out of extension/ to platform/

## Summary

### Why?

`platform/extension/buildrunner/{buildkite,githubactions}` were filed as extensions, but neither is one. Per [CLAUDE.md](CLAUDE.md), an `extension/{ext}` package holds the behavioral interface, its `Config`, and the `Factory` interface — `platform/extension/buildrunner/` had no Go package at its root at all, just two impl directories under an empty namespace. Both packages say so in their own doc comments: "It intentionally holds no BuildRunner interface or domain entity types."

What they actually are is vendor HTTP clients over `platform/http` — REST calls plus provider-specific vocabulary (Buildkite's state strings, GitHub Actions' status/conclusion pair, id encoding). That makes them siblings of `platform/http` and `platform/errs`, not extensions. The real `BuildRunner` contracts already live where they belong, at `submitqueue/extension/buildrunner` and `stovepipe/extension/buildrunner`; these clients are what those extensions' backends wrap.

### What?

Moves both packages up to `platform/buildkite` and `platform/githubactions` and deletes the now-empty `platform/extension/buildrunner/`. Pure relocation — no behavior, no signatures, no test logic changed.

Import paths and Bazel labels updated across the four consumer packages (`{submitqueue,stovepipe}/extension/buildrunner/{buildkite,githubactions}`), which keep their `platformbuildkite`/`platformgithubactions` aliases.

`platform/README.md` gains an entry for the two clients and a line on the `platform/` vs `platform/extension/` test, so the next vendor client lands in the right place.

In [doc/rfc/stovepipe/steps/build.md](doc/rfc/stovepipe/steps/build.md), only the *adopted* option is repathed. The rejected alternatives there describe a shared `BuildRunner` **interface**, which genuinely would have been an extension — so their `platform/extension/buildrunner` references are correct as written and left intact. The adopted option now also records why the shipped package is not an extension: it is precisely the option that declines to define a shared interface.

## Test Plan

- ✅ `bazel test //platform/buildkite/... //platform/githubactions/... //submitqueue/extension/buildrunner/... //stovepipe/extension/buildrunner/...` — 8/8 pass
- ✅ `bazel build //...` — 309 targets
- ✅ `make fmt` (no changes), `make lint`, `make check-gazelle`, `make check-tidy`

Author: behinddwalls

doc/rfc/stovepipe/steps/build.md

@@ -230,10 +230,10 @@ Several shapes for sharing the `BuildRunner` contract across domains were raised
 - **Shared `Status`/`Cancel` via a `platform/extension/buildrunner.StatusCanceller` sub-interface, with `BuildID`/`BuildStatus`/`BuildMetadata` promoted to `platform/base`.** An earlier draft of this doc adopted exactly this: since both domains poll and cancel by the same opaque, runner-minted id with the same async semantics, `Status`/`Cancel` moved to a shared interface embedded in each domain's `BuildRunner`, with the supporting types promoted to `platform/base` so both sides used the same Go types (a dual-implementing backend would then satisfy both interfaces through one embedded method set).
 
   Trade-offs: set aside on review — splitting one conceptual contract (`Trigger` + `Status` + `Cancel`) across two packages (`platform/extension/buildrunner` for two of the three methods, `{domain}/extension/buildrunner` for the third) fragments a single interface across an ownership boundary for a resemblance that isn't yet load-bearing: SubmitQueue is the only existing consumer of the "shared" half today, and the promotion cost — migrating SubmitQueue's already-shipped controllers, storage, and protobuf mappings onto the shared type — bought less than keeping each domain's `BuildRunner` whole and pushing reuse down to the implementation layer instead, per the option below.
-- **Shared backend under `platform`, thin per-domain contracts (adopted).** House the Buildkite / CI-gateway implementation once under `platform/extension` and let each domain define its own contract over it:
+- **Shared backend under `platform`, thin per-domain contracts (adopted).** House the Buildkite / CI-gateway implementation once under `platform/` and let each domain define its own contract over it. It sits at `platform/{backend}`, beside `platform/http`, rather than under `platform/extension/` — precisely because this option declines to define a shared interface, the package is a vendor client with no interface, `Config`, or `Factory`, so it is platform plumbing rather than an extension. Only the rejected alternatives above would have earned a `platform/extension/buildrunner` package.
 
   ```go
-  // platform/extension/buildrunner/buildkite — shared HTTP client, auth, poll loop
+  // platform/buildkite — shared HTTP client, auth, poll loop
   package buildkite
 
   type Client struct{ /* ... */ }

platform/README.md

@@ -8,7 +8,8 @@ Cross-domain packages shared by SubmitQueue, Stovepipe, and other services in th
 - **metrics/** — Tally helpers with error-aware tagging via `platform/errs`.
 - **consumer/** — Queue consumer framework (`consumer.Controller`, registry, DLQ wiring).
 - **http/** — Small HTTP client helpers (e.g. base-URL `RoundTripper`). Go import path: `github.com/uber/submitqueue/platform/http`; package name is `http`. Callers that also import `net/http` should import this package with an alias (for example `phttp "github.com/uber/submitqueue/platform/http"`) and use `phttp.NewClient`.
+- **buildkite/**, **githubactions/** — Vendor CI clients over `platform/http`: the REST calls and provider-specific vocabulary (state strings, id encoding) shared by every domain's `BuildRunner` backend. They deliberately define no interface, so they are plumbing rather than extensions — each domain keeps its own `BuildRunner` contract under `{domain}/extension/buildrunner` and adapts these clients to it.
 - **base/** — Shared domain entities (`change`, `messagequeue`, and related subpackages). Root package `base` is documentation-only.
-- **extension/** — Shared extension interfaces and implementations reused across domains (`counter`, `messagequeue`, and backends such as `mysql`).
+- **extension/** — Shared extension interfaces and implementations reused across domains (`counter`, `messagequeue`, and backends such as `mysql`). A package belongs here only if it defines a behavioral interface with its `Config` and `Factory` interface; a vendor client with no interface belongs directly under `platform/`.
 
 Domain-scoped infrastructure and extensions stay under each domain (for example `submitqueue/core/`, `submitqueue/extension/`).

…ension/buildrunner/buildkite/BUILD.bazel platform/buildkite/BUILD.bazelplatform/extension/buildrunner/buildkite/BUILD.bazel renamed to platform/buildkite/BUILD.bazel platform/extension/buildrunner/buildkite/BUILD.bazel renamed to platform/buildkite/BUILD.bazel

@@ -3,7 +3,7 @@ load("@rules_go//go:def.bzl", "go_library", "go_test")
 go_library(
     name = "go_default_library",
     srcs = ["client.go"],
-    importpath = "github.com/uber/submitqueue/platform/extension/buildrunner/buildkite",
+    importpath = "github.com/uber/submitqueue/platform/buildkite",
     visibility = ["//visibility:public"],
     deps = ["//platform/http:go_default_library"],
 )

…xtension/buildrunner/buildkite/README.md platform/buildkite/README.mdplatform/extension/buildrunner/buildkite/README.md renamed to platform/buildkite/README.md platform/extension/buildrunner/buildkite/README.md renamed to platform/buildkite/README.md

@@ -1,6 +1,6 @@
 # Buildkite client
 
-Shared HTTP client and Buildkite-specific facts for every domain's Buildkite-backed `BuildRunner`. There is no `BuildRunner` interface here by design — each domain (`submitqueue`, `stovepipe`, ...) defines its own `BuildRunner` and its own `BuildStatus`, and adapts this package's `State` to it. See [`doc/rfc/stovepipe/steps/build.md`](../../../../doc/rfc/stovepipe/steps/build.md#alternatives-considered-for-sharing-the-contract) for why the contract stays per-domain while the backend is shared.
+Shared HTTP client and Buildkite-specific facts for every domain's Buildkite-backed `BuildRunner`. There is no `BuildRunner` interface here by design — each domain (`submitqueue`, `stovepipe`, ...) defines its own `BuildRunner` and its own `BuildStatus`, and adapts this package's `State` to it. See [`doc/rfc/stovepipe/steps/build.md`](../../doc/rfc/stovepipe/steps/build.md#alternatives-considered-for-sharing-the-contract) for why the contract stays per-domain while the backend is shared.
 
 ## What lives here
 
@@ -17,7 +17,7 @@ Both wrap a `*Client` built at the wiring layer; this package never constructs o
 
 ## How the same `Client` stays safe to share across two different checkout strategies
 
-SubmitQueue's build materializes state that doesn't exist yet — the runner resolves a batch DAG into composite base/head commits by applying patches. Stovepipe's build checks out a commit that already exists on trunk and, for an incremental build, diffs it against a baseline. These are different problems at the CI-pipeline level (see [build.md's "Why separate contracts"](../../../../doc/rfc/stovepipe/steps/build.md#why-separate-contracts)), yet both go through the same `Client.CreateBuild` call — the `Client` never inspects `CreateBuildRequest.Env` or picks a strategy, so there is nothing here that needs to "know" which pattern applies.
+SubmitQueue's build materializes state that doesn't exist yet — the runner resolves a batch DAG into composite base/head commits by applying patches. Stovepipe's build checks out a commit that already exists on trunk and, for an incremental build, diffs it against a baseline. These are different problems at the CI-pipeline level (see [build.md's "Why separate contracts"](../../doc/rfc/stovepipe/steps/build.md#why-separate-contracts)), yet both go through the same `Client.CreateBuild` call — the `Client` never inspects `CreateBuildRequest.Env` or picks a strategy, so there is nothing here that needs to "know" which pattern applies.
 
 The split happens entirely outside this package, at two layers below it:
 

…xtension/buildrunner/buildkite/client.go platform/buildkite/client.goplatform/extension/buildrunner/buildkite/client.go renamed to platform/buildkite/client.go platform/extension/buildrunner/buildkite/client.go renamed to platform/buildkite/client.go

@@ -3,7 +3,7 @@ load("@rules_go//go:def.bzl", "go_library", "go_test")
 go_library(
     name = "go_default_library",
     srcs = ["client.go"],
-    importpath = "github.com/uber/submitqueue/platform/extension/buildrunner/githubactions",
+    importpath = "github.com/uber/submitqueue/platform/githubactions",
     visibility = ["//visibility:public"],
     deps = ["//platform/http:go_default_library"],
 )

…ion/buildrunner/buildkite/client_test.go platform/buildkite/client_test.goplatform/extension/buildrunner/buildkite/client_test.go renamed to platform/buildkite/client_test.go platform/extension/buildrunner/buildkite/client_test.go renamed to platform/buildkite/client_test.go

@@ -1,6 +1,6 @@
 # GitHub Actions client
 
-Shared HTTP client and GitHub Actions-specific facts for every domain's GitHub Actions-backed `BuildRunner`. There is no `BuildRunner` interface here by design — each domain (`submitqueue`, `stovepipe`, ...) defines its own `BuildRunner` and its own `BuildStatus`, and adapts this package's `RunStatus` to it. Mirrors [`platform/extension/buildrunner/buildkite`](../buildkite/README.md)'s split; see that package's README and [`doc/rfc/stovepipe/steps/build.md`](../../../../doc/rfc/stovepipe/steps/build.md#alternatives-considered-for-sharing-the-contract) for the shared rationale.
+Shared HTTP client and GitHub Actions-specific facts for every domain's GitHub Actions-backed `BuildRunner`. There is no `BuildRunner` interface here by design — each domain (`submitqueue`, `stovepipe`, ...) defines its own `BuildRunner` and its own `BuildStatus`, and adapts this package's `RunStatus` to it. Mirrors [`platform/buildkite`](../buildkite/README.md)'s split; see that package's README and [`doc/rfc/stovepipe/steps/build.md`](../../doc/rfc/stovepipe/steps/build.md#alternatives-considered-for-sharing-the-contract) for the shared rationale.
 
 ## What lives here
 

…on/buildrunner/githubactions/BUILD.bazel platform/githubactions/BUILD.bazelplatform/extension/buildrunner/githubactions/BUILD.bazel renamed to platform/githubactions/BUILD.bazel platform/extension/buildrunner/githubactions/BUILD.bazel renamed to platform/githubactions/BUILD.bazel

@@ -18,7 +18,7 @@
 // BuildRunner interface or domain entity types — each domain (submitqueue,
 // stovepipe, ...) defines its own BuildRunner and its own BuildStatus, and
 // adapts this package's RunStatus to it. See
-// platform/extension/buildrunner/buildkite's README for the analogous
+// platform/buildkite's README for the analogous
 // rationale applied to the Buildkite backend.
 package githubactions