CI: binary-size cancels its own runs on bot label events, showing PRs as failing

## Summary

`ci-binary-size-validation.yaml` cancels its own in-flight runs whenever a bot adds a label to a PR. The cancelled runs stay in the PR's check rollup, so a PR that passed the check reads as **2 failing checks** in `gh pr checks` and in the PR UI.

**25% of the last 60 runs of this workflow ended `cancelled`** (15 cancelled / 44 success / 1 failure).

## Mechanism

The workflow triggers on label events as well as pushes:

```yaml
on:
pull_request:
types: [opened, synchronize, reopened, labeled, unlabeled]

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```

The `labeled`/`unlabeled` triggers exist so the `allow-large-binaries` bypass takes effect when the label is applied. But this repo's own automation (`pr-assign-release-sheriff.yaml`, `pr-label-backport`) adds labels within seconds of a push. Each label event starts a new run in the same concurrency group, which cancels the run started by the push.

## Evidence

On https://github.com/Comfy-Org/ComfyUI_frontend/pull/15065, head `46cf8dd4`, three runs started within four seconds:

| Run | Started | Conclusion |
| --- | --- | --- |
| [31546134458](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/31546134458) | 23:21:07 | **cancelled** |
| [31546136337](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/31546136337) | 23:21:09 | **cancelled** |
| [31546137711](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/31546137711) | 23:21:11 | success |

The third run executed `scripts/cicd/check-binary-size.sh` and passed. The PR added no binary files at all — six files, all `.ts`/`.json`. There was no size regression; the check was simply cancelled twice.

## Why it matters

`binary-size` is not a required status check, so this does not block merges. It costs review attention: a PR reported as "2 failing checks" gets triaged as broken, and the real answer is only visible by opening each cancelled run. This cost one investigation cycle on #15065, which had been reported as green before the cancellations appeared.

## Suggested fix

Options, roughly in order of preference:

1. Key the concurrency group on the head SHA rather than the ref, so label events on an unchanged commit join rather than cancel:
```yaml
group: ${{ github.workflow }}-${{ github.event.pull_request.head.sha || github.ref }}
```
2. Drop `cancel-in-progress` for this workflow. It is a sub-minute job; cancellation saves little.
3. Narrow the label triggers so only the `allow-large-binaries` label re-triggers.

## Not a duplicate of #11027

https://github.com/Comfy-Org/ComfyUI_frontend/issues/11027 covers 23 workflows that **lack** concurrency control. `ci-binary-size-validation` is not in that list — this is the opposite failure mode, where existing concurrency control is too aggressive for the trigger set.

Read ci-binary-size-validation.yaml, focusing on its pull_request label triggers and concurrency settings. Inspect the linked workflow runs and evaluate the suggested fixes; done when label automation no longer leaves misleading cancelled checks in the PR rollup while the allow-large-binaries behavior still works.

Written by the indexing model from the issue text.