Auto-label merged PRs with released:core / released:cloud based on actual deployment status

## Problem

We want to automatically label merged PRs with `released:core` or `released:cloud` when they ship to users. PR #8978 attempted this by triggering on `release: published` events from `core/*` or `cloud/*` branches, but this doesn't match how releases actually work in this repo.

## How Releases Actually Work

### Core releases
- Frontend versions are published as npm packages (`comfyui-frontend-package`) and tagged with `v1.x.x` from `core/*` branches (e.g., `v1.41.20` from `core/1.41`)
- **A PR is "released on core"** when [ComfyUI's `requirements.txt`](https://github.com/Comfy-Org/ComfyUI/blob/master/requirements.txt) pins that version or greater (currently `comfyui-frontend-package==1.41.20`)
- Publishing a GitHub Release from a `core/*` branch does NOT mean core users have it -- ComfyUI must adopt it first

### Cloud releases
- Cloud deploys frontend by **commit SHA**, not by version tag
- The [cloud repo's `frontend-version.json`](https://github.com/Comfy-Org/cloud/blob/main/frontend-version.json) specifies the active release branch (currently `cloud/1.41`)
- Deployment goes through ArgoCD overlays: staging (`comfy-cloud-stg-v2/values.yaml`) then production (`comfy-cloud-prod-v2/values.yaml`), each pointing to a `frontendVersion` SHA
- The `frontend-release-prod.yml` workflow in the cloud repo creates a PR to update the prod overlay
- **A PR is "released on cloud"** when the prod overlay's `frontendVersion` SHA includes that PR's commits
- GitHub Releases are **never published** from `cloud/*` branches -- there is no `release: published` event to listen for

### Current tag/branch inventory
- All 475+ tags follow `v1.x.x` pattern (no `core/` or `cloud/` prefixed tags exist)
- Branches: `core/1.41`, `cloud/1.41`, etc. exist but releases from them use `v1.x.x` tags
- `system_stats` endpoint (`https://cloud.comfy.org/api/system_stats`) returns the deployed frontend SHA (not a version tag)

## Proposed Implementation

### Option A: Cross-repo `repository_dispatch` (recommended)

**Core trigger:**
1. Add a workflow to `Comfy-Org/ComfyUI` that fires a `repository_dispatch` to this repo whenever `requirements.txt` changes the `comfyui-frontend-package` version
2. The handler here parses the new version, maps it to a git tag (`v1.41.20`), finds the previous core version's tag, diffs the commits, and labels all merged PRs in that range with `released:core`

**Cloud trigger:**
1. Add a step to `frontend-release-prod.yml` in `Comfy-Org/cloud` that fires a `repository_dispatch` to this repo when a prod overlay PR merges (new `frontendVersion` SHA deployed)
2. The handler here maps the new and previous SHAs to commits on the `cloud/*` release branch, diffs them, and labels merged PRs with `released:cloud`

### Option B: Cron-based polling (simpler, no cross-repo changes)

A single scheduled workflow in this repo that runs periodically (e.g., every 6 hours):

1. Fetches `Comfy-Org/ComfyUI/requirements.txt` to get the current core version
2. Fetches `Comfy-Org/cloud` prod overlay to get the current cloud SHA
3. Compares against last-known values stored in GitHub repo variables (e.g., `vars.LAST_CORE_VERSION`, `vars.LAST_CLOUD_SHA`)
4. If changed, diffs commits between old and new, labels PRs accordingly
5. Updates the repo variables

### Shared concerns for either option

- **250-commit API limit:** `compareCommitsWithBasehead` caps at 250 commits (this repo regularly exceeds that between releases -- 294 commits between v1.41.0..v1.42.3). Must use paginated `listCommits` or parse PR numbers from merge-commit messages (`(#1234)` suffix) instead.
- **Rate limits:** Releases can span 100-300+ commits. Calling `listPullRequestsAssociatedWithCommit` per commit serially risks secondary rate limits. Batch with concurrency limits or extract PR numbers from commit messages.
- **Label creation:** Use `issues: write` permission and create `released:core` / `released:cloud` labels on first run if they don't exist.

## Why PR #8978 Doesn't Work

1. **Cloud releases never trigger `release: published`** -- cloud deploys via commit SHA through ArgoCD, not GitHub Releases
2. **Core labeling is premature** -- a `core/*` GitHub Release being published doesn't mean ComfyUI has adopted it in `requirements.txt`
3. **Tag matching is dead code** -- `getLabelForTag` filters for `core/` or `cloud/` prefixed tags, but all tags use `v1.x.x`
4. **Branch matching partially works** -- `getLabelForBranch` would match `core/1.41` but never fires for cloud (see point 1)
5. **250-commit truncation** -- silently drops commits beyond the API limit with no fallback

## References

- PR #8978 (the attempted implementation)
- Cloud deploy workflow: `Comfy-Org/cloud/.github/workflows/frontend-release-prod.yml`
- Cloud frontend config: `Comfy-Org/cloud/frontend-version.json`
- Core version pin: `Comfy-Org/ComfyUI/requirements.txt`
- Cloud system stats: `https://cloud.comfy.org/api/system_stats`

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-9950-Auto-label-merged-PRs-with-released-core-released-cloud-based-on-actual-deployment-s-3246d73d365081cba300e50765f544c4) by [Unito](https://www.unito.io)