feat: auto-update CAGENT_VERSION on new cagent releases

[derekmisler]

Summary

• Adds a new workflow (update-cagent-version.yml) that automatically updates CAGENT_VERSION when a new cagent release is published
• Triggered via repository_dispatch from dagent's release_cagent.yml, or manually via workflow_dispatch
• Validates the version exists as a release on docker/cagent before updating
• Exits early if already up to date
• Uses a fixed branch name (auto/update-cagent-version) so successive releases update the same PR instead of creating duplicates
• Uses the docker-agent GitHub App token with RELEASE_TOKEN fallback

Companion change

The repository_dispatch sender step still needs to be added to docker/dagent's release_cagent.yml (adds cagent-action to the app token repo list + a dispatch step at the end of the release job): https://github.com/docker/dagent/pull/328

Test plan

• Run workflow manually via workflow_dispatch with no version input (should fetch latest release)
• Run with an explicit version input (e.g., v1.28.1)
• Run twice with the same version — second run should exit early ("Already up to date")
• Run with v1.28.1, then v1.28.2 before merging — same PR should update
• Verify the dagent companion dispatch step works end-to-end after a release

[derekmisler]

/review

[docker-agent]

Review Summary

Assessment: 🟢 APPROVE

This PR introduces a new GitHub Actions workflow that automatically updates the CAGENT_VERSION file when new cagent releases are published. The implementation is well-structured with proper error handling and validation.

Key Features Reviewed:

• ✅ Version detection from repository_dispatch, workflow_dispatch, or latest release
• ✅ Release validation against docker/cagent repository
• ✅ Early exit if already up to date
• ✅ PR creation/update logic with force-push on managed branch
• ✅ Token fallback mechanism (App token → RELEASE_TOKEN → default)

Workflow Logic:
The workflow correctly handles the entire update cycle:

1. Determines version from multiple sources with proper precedence
2. Validates the version exists as a release
3. Checks current version and exits early if unchanged
4. Updates the file and creates/updates a PR on a fixed branch
5. Uses force-push safely on an exclusively-managed branch

The code is production-ready. Several potential edge cases were examined (missing file checks, token validation, concurrent runs, variable injection) but were found to be either non-issues given the repository context or handled appropriately by the workflow's design.

No blocking issues found. The workflow follows GitHub Actions best practices and should work reliably in production.