Maestro (local): queue pending runs in the maestro-test concurrency group instead of cancelling them

[andreBurnt]

Content

Add queue: max to the maestro-test concurrency group on the Maestro test suite job. One-at-a-time execution is unchanged (no cancel-in-progress); the only difference is that runs waiting for the slot now queue instead of the newest one cancelling the one already pending.

Motivation and context

Fixes #7654. With the default (queue: single), when run A is executing and run B is pending, run C finishing Build APK cancels B within a second; B's PR then has no Maestro verdict for that commit and nothing re-runs it. Two timestamped instances are in the issue. GitHub's docs for the property: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs (up to 100 pending runs, no runner cost while pending; queue: max is explicitly incompatible with cancel-in-progress: true, which this group does not use).

Screenshots / GIFs

n/a (CI only)

Tests

• actionlint 1.7.12 reports unexpected key "queue" for "concurrency" section: its schema predates the property. GitHub's workflow validator accepts it (see the docs above); the PR's own workflow run is the check.
• No behaviour change unless two runs are pending at once, so the effect is visible only on a busy morning: a run that previously showed cancelled with 0 steps will instead wait and then execute.

Tested devices

• n/a (workflow change only)

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot. (I cannot request reviewers from a fork.)
  • No.
• Changes have been tested on an Android device or Android emulator with API 24 (n/a)
• UI change has been tested on both light and dark themes (n/a)
• Accessibility has been taken into account (n/a)
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes (n/a)
• You've made a self review of your PR

Independent of #7653's PR; both touch adjacent lines of the same file, so whichever lands second I will rebase. Label: PR-Misc (cannot add from a fork).

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.