feat(orchestrator): build extension profiles from configuration

[behinddwalls]

Summary

Why?

Which implementation of each extension a queue resolved to was hardcoded: the build runner was the fake one for every queue regardless of what was available, and the change provider was a global all-or-nothing environment gate. A deployment could not run one queue against a real provider next to one running entirely on fakes, which is what a stack serving both a test environment and a live repository needs.

What?

PROFILES_CONFIG_PATH names a YAML file selecting the change provider, build runner, and conflict analyzer per queue. Each extension is independently optional, so a queue that differs only in its analyzer says only that. kind is an open string rather than a closed schema, so supporting a new provider is a new value and an implementation behind it, not a change to the file's shape.

The file holds no secret: each integration names the environment variable carrying its credential.

The pathoverlap analyzer takes a by granularity — file, or directory to coarsen a queue's conflicts to a shared parent. It defaults to file, the narrower of the two: a default that widened what conflicts would serialize a queue more than its configuration asked for.

With no config file the built-in example topology applies, reproducing the previous behavior exactly — including the per-queue analyzers the E2E suite depends on, and a routing change provider that still falls back to the fake when no token is set. That is what keeps the existing suite meaningful as a regression gate.

Extensions are reused across queues configured alike. This is load-bearing for the build runner: the build and buildsignal controllers look it up separately and the fake holds a build's outcome in memory, so two instances would lose the result between triggering a build and polling it.

Test Plan

✅ bazel test //service/submitqueue/orchestrator/server:go_default_test — pins the built-in topology against what the E2E suite expects, covers per-extension inheritance, provider defaults, every validation rejection, that queues configured alike share one build runner, that each queue's analyzer behaves as configured, and that a missing token fails at startup rather than mid-merge.

✅ Added with the by granularity: it defaults to file, directory is accepted, and an unrecognized value is rejected at load rather than at the first queue that resolves it.