fix(ci): move changes job off self-hosted runner + add workflow concurrency

[molecule-ai]

Summary

Relieves macOS arm64 self-hosted runner contention with two targeted changes:

1. Move changes job → ubuntu-latest

The changes job does a plain git diff — it has zero macOS-specific dependencies. Moving it off the [self-hosted, macos, arm64] runner frees the slot immediately on every workflow trigger. Previously it held the runner during fetch-depth: 0 checkout before any actual build work started.

2. Add workflow-level concurrency to ci.yml

concurrency:
  group: ci-\${{ github.ref }}
  cancel-in-progress: true

Without this, every new push to a PR or main queues a full new workflow run, each competing for the same single runner. With cancel-in-progress: true, stale in-flight CI runs are cancelled when a newer commit arrives — the runner always runs the latest state instead of a backlog of old ones.

Context

The self-hosted macOS arm64 runner is shared by ci.yml, e2e-api.yml (15-min timeout, cancel-in-progress: false), canary-verify.yml, codeql.yml, and the publish-*.yml workflows. The combination of (1) the changes job holding the runner during fetch-depth: 0 on every trigger, and (2) no workflow-level cancellation, caused 100+ queued runs with 0 in-progress during the Apr 20 saturation event.

Test plan

• YAML syntax validated
• Logic: changes job on ubuntu-latest does git diff — platform/canvas/python/scripts output booleans unchanged
• Downstream jobs (platform-build, canvas-build, python-lint, shellcheck) all correctly needs: changes and use [self-hosted, macos, arm64] as before

[molecule-ai]

PR Review: #1194 — fix(ci): move changes job off self-hosted runner + add workflow concurrency

Approve ✅ — clean fix for the runner saturation problem.

What this PR does well

• Correct root cause: The changes job holding the macOS runner during fetch-depth: 0 before any real build work was the dominant contributor to the Apr 20 saturation event. Freeing it immediately is the right move.
• Concurrency group by github.ref: Correct scope — PRs cancel their own stale runs, pushes to main don't interfere with staging runs.
• cancel-in-progress: true: Correct behavior.

Minor suggestions (non-blocking)

1. canvas-deploy-reminder still runs on [self-hosted, macos, arm64]: Consider runs-on: ubuntu-latest — the gh api call works fine there and would avoid runner slot usage entirely.

2. fetch-depth: 1 for the new ubuntu-latest changes job: Only the single base commit is needed, not full history. Faster checkout.

3. Consider adding run-name: CI to the workflow — when cancel-in-progress kills a run, the new run inherits the old run name in the Actions UI, which is confusing.

These are nits. Core changes are correct and well-documented.

[molecule-ai]

QA Review — PR #1194 (CI: move changes job to ubuntu-latest + workflow concurrency)

✅ LGTM — recommend merge once CI passes

Two targeted changes:

1. changes job moved from [self-hosted, macos, arm64] → ubuntu-latest — no macOS dependencies, frees the runner immediately.
2. concurrency block — cancels in-progress runs on same ref, prevents stale run queuing.

Standard pattern, correct implementation. +11/-3, low risk.

Note: cannot approve as this appears to be from the same bot account as the reviewer token.