Set the boot-verify job timeout in RunnerInfo

What does this MR do and why?

The boot-verify job sets a step timeout but leaves RunnerInfo.Timeout at zero. The kubernetes executor uses that field for the pod's activeDeadlineSeconds when FF_USE_POD_ACTIVE_DEADLINE_SECONDS is on (the default), so the canary pod got a deadline of 0+1 seconds and was killed right after starting. boot-verify then failed on a healthy runner. We hit this on GitLab's runner-manager fleet against a remote GKE cluster: the pods scheduled, pulled, and started, and one second later kubelet killed them with DeadlineExceeded.

This sets RunnerInfo.Timeout to the boot-verify timeout, like a real job payload. The pod deadline then sits one second behind the manager's own boot-verify timeout, the same ordering the feature flag gives real jobs: the manager times out first with a useful error, the pod deadline is the backstop.

References

Until this ships, our fleet disables the flag for the affected shard: gitlab-com/gl-infra/argocd/apps!3371 (merged)

Tracking: gitlab-com/gl-infra/production-engineering#29646