ci: trigger the docs reference regeneration on release

[Rachael-Graham]

Draft until the secrets below exist.

Why

kagent-dev/website regenerates the kagent reference docs — the CRD API reference, the Helm values reference, the CLI pages and the version conrefs. It did that nightly from kagent main, which meant the 1.x docs described code no released kagent contained, while the helm install --version line on those same pages named an older release. The 2026-09-22 run documented KagentHarnessCompaction and KagentHarnessSummarizer on pages pinned to alpha1, a release neither type exists in.

That workflow now builds from a release tag (kagent-dev/website#500), so it needs to know when a release happened. on: release can't fire in website for a release published here, so kagent has to tell it.

What this adds

One job that dispatches a kagent-release event carrying the version.

It runs after release on purpose — the docs workflow looks the release up by tag and resolves runtime image digests from GHCR, so both have to exist first. It's continue-on-error because a missed docs ping is recoverable by dispatching that workflow by hand, and isn't worth failing a release over.

The version is sent explicitly rather than letting the docs side fall back to "latest release", so re-running an older tag regenerates that release rather than whatever is newest.

What's needed before this can merge

Two Actions secrets in this repo, from a GitHub App owned by kagent-dev:

• APP_ID
• APP_PRIVATE_KEY

The App needs Contents: Read and write, installed on kagent-dev/website only. That's the sole permission repository_dispatch requires. An org owner has to create it — GITHUB_TOKEN is scoped to this repository and can't dispatch across repos.

A fine-grained PAT with the same permission works too, if that's preferred; it's a two-line change here.

🤖 Generated with Claude Code

[Rachael-Graham]

Closing: we're going with the pattern the sibling docs repos already use instead.

agentgateway/website and kgateway-dev/kgateway.dev each publish their own "Docs for vX" release and read its tag to decide which code tag to build from. That's a human-operated switch that needs no cross-repo credentials, so no GitHub App and no change in this repo.

kagent-dev/website#500 now triggers on a release published there, tagged with the kagent release to document. Thanks @EItanya for pointing at the peer precedent.