Retry jobs interrupted by external termination

What does this MR do?

Adds runner_interrupted to the project's default job retry, next to the existing runner_system_failure.

Why was this MR needed?

A merge train pipeline (https://gitlab.com/gitlab-org/gitlab-runner/-/pipelines/2650397191) failed because the test coverage report job's VM got reclaimed mid-run. The job died 13 seconds into make cobertura_report with Job failed: aborted: terminated and failure_reason: runner_interrupted. Everything else in the pipeline was green, and the train cost a full cycle.

The default retry in _common.gitlab-ci.yml only fires on runner_system_failure. Before runner_interrupted existed as its own failure reason, this kind of interruption was reported as runner_system_failure and got retried by that default. Once the reason was split out, the retry config stopped matching it. So this restores behaviour we used to have rather than adding anything new.

It matters here in particular because the project's default runner tag is the pilot autoscaler fleet (functions-pilot-linux-amd64), where instance reclaims are routine.

Retries still show up in job history and metrics, so if the fleet ever starts reclaiming aggressively the signal is still there.

What's the best way to test this MR?

retry:when: [runner_interrupted] validates against gitlab.com CI lint. Beyond that, the next VM reclaim will test it for us.

What are the relevant issue numbers?

Closes #39582 (closed)