CI tooling: automate version pins in .buildkite/pipeline.yml

# CI tooling: automate version pins in `.buildkite/pipeline.yml`

## Problem

All CI tool versions used by the `integrations` pipeline are pinned as plain
env vars at the top of `.buildkite/pipeline.yml`:

```yaml
env:
SETUP_GVM_VERSION: "v0.6.0"
DOCKER_COMPOSE_VERSION: "v2.24.1"
DOCKER_VERSION: "26.1.2"
KIND_VERSION: "v0.32.0"
K8S_VERSION: "v1.36.1"
YQ_VERSION: "v4.35.2"
JQ_VERSION: "1.7"
GH_CLI_VERSION: "2.29.0"
```

None of these are updated automatically. The existing updatecli setup
(`.github/workflows/bump-elastic-stack-version.yml`) and dependabot config
(`.github/dependabot.yml`) only cover `STACK_VERSION` in the schedule pipelines
and Go/GitHub Actions dependencies respectively — they never touch
`pipeline.yml`.

Consequence: pins drift silently and require manual review to notice. As a
concrete example, `DOCKER_VERSION` has been frozen at `26.1.2` since January
2024 (elastic/integrations#8949), while the runner image
`platform-obs-integrations-ubuntu-2204` now ships Docker `29.7.2`. Every CI job
spends time on an apt downgrade that may no longer be necessary, and there is no
automated signal that the pin has fallen behind.

This was surfaced during investigation of [Buildkite build #49212](https://buildkite.com/elastic/integrations/builds/49212),
whose actual root cause was a transient GitHub releases 504 (fixed in
elastic/integrations#21120) — but the investigation highlighted that these pins
have no automation behind them.

## Goal

Reduce maintenance burden and avoid version drift by automating updates for the
CI tools listed above, generating PRs the same way dependabot does for Go
modules.

## Proposed approach

Extend the existing updatecli pipeline with one manifest per tool that:

1. **Sources** the latest release tag from GitHub (all tools above are published
as GitHub releases).
2. **Targets** the corresponding env var line in `.buildkite/pipeline.yml` using
a `matchpattern` / `replacepattern` pair (the same pattern already used for
`STACK_VERSION` in the schedule pipelines).
3. **Opens a PR** via `github/pullrequest` when the version changes, labelled
`automation` and `dependency`.

Example manifest skeleton for `KIND_VERSION`:

```yaml
sources:
latestKind:
kind: githubrelease
spec:
owner: kubernetes-sigs
repository: kind
versionfilter:
kind: latest

targets:
updateKindVersion:
kind: file
sourceid: latestKind
spec:
file: '.buildkite/pipeline.yml'
matchpattern: '(KIND_VERSION:) ''[^'']*'''
replacepattern: "$1 '{{ source \"latestKind\" }}'"
```

## Scope and constraints

- **`DOCKER_VERSION`** — handle with care. The `26.1.2` pin was a deliberate
downgrade (elastic/integrations#8949). Before adding automation, investigate whether the pin
is still required or whether `DOCKER_VERSION: "false"` (skip the install,
use whatever the runner image ships) is now the right default.
Automating a blind bump here could re-introduce the original issue that caused
the downgrade.
- **`K8S_VERSION` / `KIND_VERSION`** — `backport_branch.sh` intentionally
preserves these lines when syncing `pipeline.yml` to backport branches
(`backport_branch_lib.sh:148-174`). Any updatecli bump must open a PR against
`main` only, not backport branches. This is already the default behaviour.
- The manifest should run on the same schedule and in the same workflow as the
existing updatecli job (weekdays at 01:00 UTC).

## Related

- elastic/integrations#21120 — fixed the actual root cause of the build failure (silent curl writes on HTTP errors)
- [Buildkite build #49212](https://buildkite.com/elastic/integrations/builds/49212) — the failure whose investigation surfaced the lack of pin automation

Start with .github/workflows/bump-elastic-stack-version.yml and the existing STACK_VERSION updatecli configuration, then inspect .buildkite/pipeline.yml and its version-pin lines. Add manifests for the applicable tools, preserve the main-branch behavior for K8S_VERSION and KIND_VERSION, and resolve whether DOCKER_VERSION should remain pinned before automating it. Done means scheduled updatecli runs can open correctly labelled PRs for changed pins.

Written by the indexing model from the issue text.