Add verify_helper_version to the boot-verify canary

What does this MR do?

Adds an opt-in verify_helper_version check to the boot-verify canary. It runs a new verify-version helper subcommand in the helper environment with the manager's version as the expected value, and fails the canary on a mismatch. Strict equality on the version string for now; slack (for example matching on the tagged release only) can come later if wanted.

It runs before the other probes: those run through the same binary, so a version mismatch explains their failures.

Why was this MR needed?

Runners with an explicitly pinned helper_image can drift from the manager's version, and the mismatch surfaces as unrelated job failures instead of a clear verdict at startup. The probes in the parent MR also require a matching helper, so this check turns "probe failed strangely" into "your helper is version X, the runner is version Y".

Doing the comparison inside the binary rather than in shell is what makes it work identically on every OS and shell. Helper images too old to carry the subcommand fail with an unknown-command error: still the correct verdict, just a less specific message.

What's the best way to test this MR?

Unit tests cover the comparison and the script generation. I also ran it on a docker+machine deployment against real GCP: with runner and helper built from the same source the canary passes, and with a pinned older helper image the canary fails and the manager never reports Ready.

What are the relevant issue numbers?

Stacked on !7214 (merged).

• gitlab-com/gl-infra/production-engineering#29623 (closed) (the Windows shard ran a badly outdated helper, which prompted this check)
• gitlab-com/gl-infra/ci-runners&29 (closed) (runner-manager centralization this hardening supports)