Add runner, system_id and result labels to GetJob duration metric

What does this MR do?

Adds runner, system_id and result labels to gitlab_runner_job_router_get_job_duration_seconds.

Why was this MR needed?

The metric shipped unlabeled, so every GetJob observation from a runner process collapsed into a single series. Operators could not break latency down per runner entry or correlate regressions during Job Router rollouts.

result (job/no_job/error) goes beyond the issue's acceptance criteria. Without it the histogram stays hard to read: a no-job long-poll waits out GitLab's CI polling window, so it swamps the latency tail of every other outcome. It also mirrors the Relay-side job_router_get_job_duration_seconds, which already breaks down by result, so the two sides can now be compared the same way.

Cardinality is bounded by the [[runners]] entries on a host: 39 series each, well under what gitlab_runner_api_request_duration_seconds already costs per entry.

What's the best way to test this MR?

See unit tests.

What are the relevant issue numbers?

• Add `runner`/`system_id` labels to `gitlab_runn... (#39576 - closed)