gitlab-runner role: gitlab-runner binary not found after install

[yakari007]

Summary

Deployed a VM with the gitlab-runner service role attached
(gitlab_url/registration_token left empty, so per the role's own
description it should install but stay unregistered), on the Ubuntu 24.x
"with PlusClouds Service" image. After SSH login succeeded:

• systemctl is-active gitlab-runner reported inactive (unit exists but
  not running - not "no such unit")
• sudo gitlab-runner status failed with sudo: gitlab-runner: command not found

The binary itself not being on PATH is stronger evidence than a systemd
symptom alone - this looks like the install step (apt/dnf repo add +
package install) didn't actually complete, not just a registration/startup
issue.

Repro

POST /leo/iaas/virtual-machines/create-wizard with
service_roles: {"gitlab-runner": {"config": {}}} against the Ubuntu 24.x
"with PlusClouds Service" image, then after boot:

systemctl is-active gitlab-runner   # -> inactive
sudo gitlab-runner status           # -> sudo: gitlab-runner: command not found

The VM was deployed and torn down automatically as part of the test run,
so the live VM/install-script output is gone - filed from the test's
captured output, not a live inspection.

Found via leo4.tester's iaas-service-roles automated test scenario.

[yakari007]

Investigated but did not find a reproducible code-level bug, so no change made yet.

Fetched and read through GitLab's actual packages.gitlab.com install script (the exact one the role pipes to bash) — it's a well-written script with set -e and explicit exit-code checks on every curl call, so a transient network failure during repo setup would make the script itself exit non-zero (which ansible's shell task would correctly catch and fail on), not silently no-op. I also confirmed the creates: /etc/apt/sources.list.d/runner_gitlab-runner.list idempotency guard matches the exact filename the script writes. I couldn't find a deterministic defect in the role as written — my best guess is this was a transient network hiccup during that specific test run (in the same spirit as #2's flakiness), but I can't confirm without a live repro. If it happens again, the ansible run's own stdout/stderr (not just the resulting VM state) would show exactly which step failed.