Automate dependency updates with Renovate

[NickJosevski]

Description

Yes — this is a job for Renovate, which is what the rest of the org uses for dependency
bumps (~48 repos, e.g. tool-containers, nautilus-workloads, Binnacle-*, OctoVersion). It is self-hosted through
the renovatebot/github-action action rather than the Mend app, so this PR follows the same shape as those repos:
a renovate.json plus a scheduled workflow. release-please is also used in the org, but that solves versioning and
changelogs, which changesets already does for us here — it wouldn't have raised #690.

With this in place, a monitor release like #690 arrives as a
ready-to-merge PR: Chart.yaml, Chart.lock (Renovate runs helm dependency update for the OCI dependency) and the
changeset.

What's in scope

Manager	Target branch	Changeset
helmv3 — kubernetes-monitor-chart in charts/kubernetes-agent/Chart.yaml	release/kubernetes-agent/v2	added automatically
github-actions — action versions in our workflows	main	not needed
npm — @changesets/cli, cross-env	main	not needed

Two deliberate decisions worth reviewing:

• Chart dependencies are raised against the oldest active release stream, not main. That is where Update Kubernetes monitor to 0.37 #690 went, and it
  keeps updates inside the forward merge process.
  The cost is that baseBranchPatterns names release/kubernetes-agent/v2 explicitly and has to be updated when a
  release stream is retired or added — called out in that doc.
• helm-values (image tags in values.yaml) is disabled. agent.image.tag has to move in lockstep with
  Chart.yaml appVersion (enforced in kubernetes-agent-publish-chart.yaml) and worker-tools isn't semantically
  versioned, so those stay manual. nfs-server / nfs-watchdog could be enabled later.

Otherwise the config is the org's house style: dependencies + datasource labels, dashboard issue, assignees from
CODEOWNERS, prConcurrentLimit: 1, and a 3 day minimumReleaseAge — waived for kubernetes-monitor-chart since we
publish it ourselves.

Blocker before this can be merged

A RENOVATE_GITHUB_TOKEN repository secret is needed. It's a per-repository secret elsewhere (not an org secret — this
repo only inherits CHANGESETS_GITHUB_TOKEN and friends), and the PRs in the other repos are raised by
team-builds-bot, so Build Platform needs to provision it here. Until it exists the Renovate job will fail on the
missing token, which is why this is a draft.

Testing

The workflow runs on pull requests that touch renovate.json or the workflow itself, with RENOVATE_DRY_RUN=full, so
once the token lands this PR validates its own config and logs exactly which updates it would raise — check the log for
the Chart.lock artifact update and the .changeset/renovate-*.md post upgrade task before merging.

Validated locally: renovate.json parses, the RENOVATE_ALLOWED_COMMANDS regex matches the fully templated printf
command, and that command produces a changeset byte-identical in shape to the hand-written one in #690.

Pre-requisites

• I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• I have added a changeset with an appropriate customer facing description.
  • Not applicable: workflow and config only, no chart change.
• I have considered appropriate testing for my change.
• This PR affects all release versions and will need to be forward merged.
  • Not needed: renovate.json is only ever read from the default branch.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9b9dfa6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR