Auto-fire dotCMS release when a PR labeled 'PR: Release after merge' is merged

Description

When a pull request is labeled PR: Release after merge, the merge of that PR into main should automatically trigger the dotCMS release process (.github/workflows/cicd_6-release.yml) — no manual workflow_dispatch needed.

The triggering workflow must compute the release version automatically by following the repo's release tag formula, v{yy.mm.dd}-## (e.g., v26.09.02-01 → v26.09.02-02), where ## is a zero-padded, two-digit daily counter (UTC date). Version calculation must be release-aware:

1. Existing tags: read today's v{yy.mm.dd}-## tags and step over the highest counter.
2. In-flight releases: scan cicd_6-release.yml runs that are queued or in progress and parse their versions from the run name (Release <version>), stepping over them too — their tags don't exist yet.
3. Collision safety: re-verify the computed tag against the remote before dispatching (the release-prepare phase force-overwrites colliding tags/branches, so a silent collision would be destructive).

Design decisions:

• Lives on the pull_request: closed lifecycle (like issue_post-pr-merge.yml), not in the merge queue — the merge queue runs before merge and is a validation gate, not a post-merge hook.
• Serialized via a dedicated concurrency group so two labeled PRs merging simultaneously each get their own increment.
• Dispatches with CI_MACHINE_TOKEN, not github.token — events created with the default GITHUB_TOKEN do not trigger other workflow runs (recursive-workflow prevention).
• Only PRs merged into main are released (mirrors the Release workflow's own verify-branch gate).
• Propagates the merged PR's SDK Breaking Change label to bump_min_sdk_version; the Release workflow's verify-branch gate re-scans all merged PRs since the last tag and fails loudly if anything was missed.
• Comments on the merged PR with the queued version and run URL for observability.

Acceptance Criteria

• A PR labeled PR: Release after merge that merges into main triggers a release automatically
• The computed version follows yy.mm.dd-## with the counter = max(existing tags, in-flight runs) + 1
• A release already queued/running for today results in the next version incremented past it
• Two labeled PRs merging at the same time never compute the same version
• PRs without the label, or merged into non-main branches, trigger nothing
• SDK Breaking Change on the merged PR results in bump_min_sdk_version=true on the dispatch
• The merged PR gets a comment with the queued release version and run URL

Priority

Medium

Read .github/workflows/cicd_6-release.yml and compare the post-merge lifecycle handling in issue_post-pr-merge.yml. Implement and verify the closed pull-request path for labeled PRs merged into main, including version handling, concurrency, dispatch, and PR comments. Done means the acceptance criteria pass without affecting unlabeled or non-main merges.