chore(ci): merge queue 방출을 자동 처리한다 — 조용한 방출은 한 번 재투입, CI 실패는 실패 job 링크 코멘트 (#1892)

[OnlyReadOneBook]

📌𝘐𝘴𝘴𝘶𝘦𝘴

• Closes chore(ci): merge queue 방출을 자동 처리한다 — 조용한 방출은 한 번 재투입, CI 실패는 실패 job 링크 코멘트 #1892

📎𝘞𝘰𝘳𝘬 𝘋𝘦𝘴𝘤𝘳𝘪𝘱𝘵𝘪𝘰𝘯

merge queue(#1477)에 넣은 PR 은 결과를 «보러 가야만» 알 수 있었다 — 조용히 방출되면 다시 넣어 줘야 하고, merge group CI 가 실패해도 PR 화면엔 «removed from the merge queue» 만 남는다. 그래서 MERGED 를 볼 때까지 PR 을 붙잡고 있어야 했다. pull_request_target 의 dequeued 이벤트로 그 둘을 자동 처리한다.

• .github/workflows/merge-queue-dequeue.yml — pull_request_target: [dequeued]. stack-integrity-notify.yml 과 같은 경계: default branch 의 워크플로 정의·스크립트만 실행하고 PR 코드·artifact·cache 는 체크아웃하지 않는다. permissions: {} + job 에만 actions: read · contents/issues/pull-requests: write. 토큰은 github.token.
• .github/scripts/handle-merge-queue-dequeue.mjs — 판정 순서:
  1. live 상태가 정본 — MERGED·CLOSED 거나 이미 큐에 있으면 무동작(이벤트는 runner 대기 중 순서가 뒤집힌다).
  2. 마지막 투입 이후 이 PR 의 큐 브랜치(gh-readonly-queue/<base>/pr-<N>-*) merge_group run 에 failure·timed_out job 이 있으면 → 실패 job 링크 코멘트, 재투입 없음. 큐 브랜치 이름은 head 가 아니라 base SHA 라 며칠 전 투입의 실패 run 도 같은 접두어로 잡히므로, timeline 의 AddedToMergeQueueEvent 시각으로 자른다(0904 feat(afternote): 수신자 선택 반환 채널을 복수로 열어 한 번에 N명 지정 (#1426) #1582 드라이런에서 확인).
  3. payload reason 이 MANUAL·ALREADY_MERGED·MERGE(D) 면 무동작. reason 의 열거값은 GitHub 이 문서화하지 않았고 timeline 은 failed_checks·merged 소문자라 대문자로 맞춰 비교한다 — 그래서 실패 여부는 reason 이 아니라 ②의 데이터로 판정한다.
  4. 그 밖(조용한 방출) → 같은 head SHA 당 한 번만 enqueuePullRequest. 횟수는 마커 코멘트(<!-- merge-queue-dequeue:requeued head=<sha> -->)로 세고, 마커를 먼저 남긴 뒤 재투입한다(재투입 뒤 코멘트가 실패하면 다음 방출에서 두 번째 재투입이 나간다). 같은 head 의 두 번째 방출은 재투입 없이 코멘트만. 0902 에 감시 루프가 90초마다 맹목 재투입해 30분 헛돈 사고(fix(receiver): 재진입 갱신 결선의 잔재를 지우고 결선 소실을 가드로 막는다 (#1725) #1638·refactor(core): 라디오 단품 직접 사용을 막고 그룹 API 로 유도한다 (#1728) #1639)가 «한 번까지» 의 근거다.
• create-ci-config.test.mjs — pull_request_target 허용 목록을 둘로 늘리고, 종전에 stack-integrity-notify.yml 에만 걸던 불변식(권한 비움·default branch ref·PR head 미참조·download-artifact/cache 미사용·secrets 미참조)을 둘 다에 건다.

실측

• 0830 refactor(afternote): 저장 실패 변환을 Result 확장 관례로 통일 (#1508) #1509 «조용한 방출» 로 기록된 건은 timeline 으로 보면 failed_checks 였다 — 폴링이 실패 job 을 못 본 것. 이 스크립트는 job 결론을 직접 읽으므로 같은 건에서 실패 링크 코멘트를 남긴다.
• 드라이런(실 API 읽기, 쓰기 없음): #1582 reason=failed_checks head=3583c34 마지막투입=2026-09-04T08:06:03Z 실패job=1 → comment-failure — 오늘 17:06 투입·17:18 방출된 실제 건이 그대로 잡힌다.

로컬: node --test .github/scripts/*.test.mjs 561/561 · actionlint · scripts/repository-quality.sh 통과.

🧪 CI Test Plan

{
  "androidTest": {
    "mode": "none",
    "reason": "워크플로 1개·정책 스크립트 1개·정책 테스트 2개(신규 1·목록 갱신 1)만 더한다. Android 소스·androidTest·navigation 경계·매니페스트·빌드 파일·managed-device 워크플로는 건드리지 않아 계측이 검증할 대상이 없다. 판정 로직은 node --test 로 fake API 위에서 전량 고정했고 실 API 는 dry-run 으로 읽기만 확인했다."
  }
}

📷𝘚𝘤𝘳𝘦𝘦𝘯𝘴𝘩𝘰𝘵

없음 — 워크플로·스크립트만.

💬𝘛𝘰 𝘙𝘦𝘷𝘪𝘦𝘸𝘦𝘳𝘴

• 자동 전파(develop 전진마다 열린 PR 전량 update-branch)는 일부러 하지 않는다. 큐가 이미 최신 base 에서 검증하고, 열린 PR 수만큼 CI 가 곱해진다.
• dequeued 를 pull_request 가 아니라 pull_request_target 으로 받는 이유: 충돌 PR 은 merge ref 가 없어 pull_request 워크플로가 트리거되지 않는다(fix(ci): base 와 충돌한 PR 은 pull_request CI 가 트리거되지 않아 최신 커밋이 미검증으로 방치 — 충돌 자동 감지·라벨 필요 #1028). 사유 판정과 코멘트에는 PR 코드가 필요 없다.
• 첫 실제 발화에서 payload reason 문자열이 로그(reason=…)에 남는다. 값이 확인되면 NO_ACTION_REASONS 를 그 표기에 맞춰 좁힐 수 있다.