Record the runner machine assignment when a build starts running

Related MRs

1. !244035 (merged) — schema + read-side groundwork
2. !247560 (merged) — persist Ci::BuildRuntimeEnvironment on suspend
3. This MR — record the runner machine assignment when a build starts running
4. !247562 — resolve runner_machine_id when queuing a suspend/resume build
5. !247563 — consume the routed runner machine when assigning jobs
6. !247564 — retire the old environment_key string-matching routing mechanism

What does this MR do and why?

Third MR in the resumed-CI-job routing stack. !247560 (merged) gave us a Ci::JobRuntimeEnvironment row recording intent to suspend; this MR records the missing data needed to route a follow-up job back correctly: which runner machine actually ran the suspending build.

Rails already learns the assigned runner_manager the moment a build transitions to running. This MR just persists that onto the build's build_runtime_environment row at that exact moment, gated behind ci_suspendable_environment_runner_routing. That timing matters: assigning the runner manager only once the job starts running (not at queue time) avoids a race where a job could be requeued to a different runner between assignment and start.

Part of routing resumed builds to the runner machine that holds their suspended environment Resumable Jobs for CI and Agent Sessions (gitlab-org#21159).

References

Issue: Resumable Jobs for CI and Agent Sessions (gitlab-org#21159)

Blueprint: Add blueprint for suspendable environments (gitlab-com/content-sites/handbook!18954 - merged)

How to set up and validate locally

Run the spec file spec/models/ci/build_spec.rb, there is no end to end test for this changeset.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.