Draft: Add documentation for GitLab Functions (concrete) execution

What does this MR do?

Adds public documentation for GitLab Functions (concrete) script execution: the benefits over the traditional shell path (including the Kubernetes signal/background-process defects that are structurally absent under concrete), per-executor support and version requirements, how to enable it at runner or job level, and helper image selection.

Key user-facing subtleties documented:

  • On the docker executor the concrete helper-image flavor is auto-selected when FF_CONCRETE is on, but an explicit helper_image/helper_image_flavor override bypasses that — users must pick a concrete-<arch>-<version> tag themselves.
  • On the kubernetes executor the concrete flavor is never auto-selected; helper_image must be set explicitly.
  • GitLab Runner 19.3+ recommended (else-branch fix, #39610 (closed)).

Also links the FF_CONCRETE row in the feature-flags table to the new page.

Why?

The migration epic (&21165 (closed)) is moving to customer-facing rollout; users on GitLab.com should be able to trial concrete on a single project and feed back divergences before their fleet is migrated. There was no public documentation for any of this.

Relates to step-runner#405 (docs follow-ups for executor enablement).

🤖 Generated with Claude Code

Merge request reports

Loading