用途：解释并执行 dtctl 的发布流程。该流程由 release-please 自动化，但不会在普通合并到 main 时触发，必须手动运行工作流。没有手动版本号提升、无需编辑 CHANGELOG.md、也无需手动推 tag；版本与发布说明由自上次发布以来的 Conventional Commits 计算得出。
主要能力：release.yml 仅在 workflow_dispatch 时运行。完整发布是两次 dispatch 中间夹一次合并。第一次 dispatch 的 release-please 任务检查提交，打开或更新标题类似 chore(main): release 0.31.0 的 release PR，其中提升 .release-please-manifest.json、pkg/version/version.go 中的回退版本（通过 // x-release-please-version 注解），并在 PR 正文包含待发布说明。合并该 PR 后，第二次 dispatch 让 release-please 创建 git tag（vX.Y.Z）和 GitHub Release，release_created == true 触发 goreleaser 任务：构建跨平台二进制、用 cosign 签名校验和、用 syft 生成 SBOM，附加到 release（release.mode: keep-existing，不覆盖说明），并把更新后的 Homebrew cask 推送到 dynatrace-oss/homebrew-tap。仓库按设计没有 CHANGELOG.md，GitHub Release 即规范变更日志。
版本提升由提交类型决定：feat: 为 MINOR；fix: / perf: 为 PATCH；feat!: / fix!: 或 BREAKING CHANGE: footer 在 1.0 前为 MINOR；docs: / test: / chore: / ci: / refactor: 单独不发布。PR 采用 squash 合并，PR 标题即发布相关提交。
使用方式：依次执行 gh workflow run release.yml、gh run watch；用 gh pr list --search "chore(main): release in:title" --state open 查看并 gh pr merge <number> --squash 合并；再次 gh workflow run release.yml 并 gh run watch；最后用 gh release view 确认。可选地用 gh release edit vX.Y.Z --notes-file notes.md 润色说明。
限制与排错：合并 release PR 本身不会发布任何内容，必须第二次 dispatch。没有 release PR 可能是未触发工作流、无可发布提交或提交不符合规范。版本提升错误源于提交类型，可用 Release-As: x.y.z footer 强制。无二进制需检查 goreleaser 任务与 release_created。Homebrew 未更新需检查 HOMEBREW_TAP_APP_ID / HOMEBREW_TAP_APP_PRIVATE_KEY 密钥与日志，skip_upload: auto 会跳过预发布标签。