CI: Jules jules.yml — three event-triggered jobs still lack queue: max, a third arrival silently drops the pending run #383

Problem

In .github/workflows/jules.yml, three of the four jobs declare a concurrency group with cancel-in-progress: false but no queue: max:

• weekly-cleanup — jules.yml:57-59
• issue-labeled — jules.yml:78-80
• ci-failure-fix — jules.yml:98-105

The fourth job in the same file, manual (jules.yml:120-123), does have queue: max — added by #359 / PR #364, which fixed exactly this defect for the dispatch-triggered groups. The three event-triggered groups in this file were not part of that fix.

Why it matters

With cancel-in-progress: false and no queue, GitHub's default queueing keeps only a single pending run per concurrency group: when a run is active and one is already pending, a third arrival silently replaces (drops) the pending run — no failure, no notification, the dropped work simply never happens.

Concrete drop scenarios, all using the file's own group keys:

• ci-failure-fix (group per workflow-name + branch): the same workflow fails again on the same branch while a fix run is active and another is pending — the pending fix attempt, whose prompt points at a specific failing run URL, is dropped.
• issue-labeled (group per issue number): the jules label is applied, removed, and re-applied (or applied in quick succession around an edit) while a run is active + pending — the pending invocation is dropped.
• weekly-cleanup (single shared group): lower risk (weekly cron), but it is the same one-line inconsistency.

This is the same defect class already fixed and accepted in this repo and its sister repos: #359 (this file's manual job + daily Jules workflows), #302 (auto-assign), opencode #151, openchamber #133/#77.

Verification (this run, on current main b40e01b)

Parsed the workflow with a YAML loader and enumerated every job's concurrency block:

weekly-cleanup {'group': '...-weekly-cleanup', 'cancel-in-progress': False}
issue-labeled  {'group': '...-issue-${{ github.event.issue.number }}', 'cancel-in-progress': False}
ci-failure-fix {'group': '...-ci-failure-fix-...-${{ ...head_branch }}', 'cancel-in-progress': False}
manual         {'group': '...-manual', 'cancel-in-progress': False, 'queue': 'max'}

Single-repo: no weekly-cleanup / ci-failure-fix / issue-labeled job exists in developing-today/opencode, developing-today/openchamber, or dezren39/nix workflows (grep-verified), so this is not a cross-repo set. A repo-wide scan of this repo's workflows shows jules.yml is the only file with cancel-in-progress: false groups still missing queue.

Acceptance criteria

• All three jobs above declare queue: max alongside cancel-in-progress: false (matching the manual job in the same file).
• Workflow still parses as valid YAML and the groups / group keys are unchanged (only the queue property is added).
• No other workflow in the repo has a non-cancelling concurrency group without queue: max (re-run the scan to confirm).

Suggested fix: add the single line queue: max under each of the three concurrency: blocks — a three-line diff.