fix(platform): 스택 PR 의 merge queue 재투입을 REST merge-async 로 보내고 결과를 확인한다 (#2177)

[OnlyReadOneBook]

Closes #2177

읽을 곳: .github/scripts/handle-merge-queue-dequeue.mjs 의 enqueueStacked, isStackBottom, handleDequeue 의 requeue 분기. 테스트는 같은 이름의 .test.mjs 에서 "2026-09-27 #2177" 절.

변경

• 스택 판정: live 조회에 stack { number baseRefName } 를 얹는다. stack 이 null 이면 비스택이고 종전 GraphQL enqueuePullRequest 경로 그대로다.
• 스택 밑단(PR base 가 스택 base 와 같음)의 재투입은 PUT /repos/{owner}/{repo}/pulls/{n}/merge-async 에 merge_action: "merge_queue", sha: <판정한 head> 로 보낸다.
• merge-async 는 202 pending 과 uuid 만 돌려주므로 GET .../merge-async/{uuid} 를 5초 간격 최대 24회 읽는다. enqueued·merged 면 성공, failed 면 예외로 job 이 red 로 남는다. 끝까지 pending 이면 live 큐 상태를 다시 읽어 큐에 없으면 예외다. 200(이미 큐)은 폴링 없이 끝난다.
• 스택 위쪽 PR 은 자동 재투입하지 않는다. merge-async 가 downstack 의 열린 PR 까지 함께 넣어서, 위쪽 PR 의 재투입이 아래 PR 의 판정(실패 job 이면 재투입 안 함)을 덮기 때문이다. 위쪽 PR 에는 마커 없는 안내 코멘트만 남기고 action 은 comment-stack-upper 다.
• 판정표 decide() 와 NO_ACTION_REASONS, 마커 선기록 순서는 바꾸지 않았다. MERGE_CONFLICT 사유는 지금처럼 한 번 재투입하고 다시 빠지면 give-up 코멘트다.
• 실패 코멘트와 give-up 코멘트의 수동 재투입 명령은 스택이면 gh stack merge <N> --yes, 아니면 gh pr merge <N> --repo ... 다. gh pr merge 는 스택 PR 을 거부하고, gh stack 에는 --repo 플래그가 없다(gh 2.85).
• 결과와 스텝 요약에 스택 번호와 재투입 수단(merge-async, graphql)을 남긴다. 워크플로 yml 과 저장소 설정은 손대지 않았다.

근거

• 실측 두 건: run 36234628071 (refactor(setting): 설정 전용 저장소와 좁은 주입 계약 분리 (#1429) #2123, 0926), run 35416998373 (refactor(setting): presentation을 기능별 폴더로 정리 (#1088) #2053, 0919). 둘 다 requeue 판정 뒤 enqueuePullRequest 가 UNPROCESSABLE "This pull request is part of a stack and must be enqueued using the asynchronous merge REST API" 로 죽었고, 마커 코멘트만 남아 다음 방출은 give-up 이 됐다.
• API 정의는 OpenAPI 원문의 PUT merge-async, GET merge-async/{uuid} 를 따랐다. 문서: https://docs.github.com/rest/pulls/pulls#merge-a-pull-request-asynchronously
• 비스택 PR 은 pullRequest.stack 이 null 로 온다(build(app): app 이 직접 쓰지 않는 feature:afternote:domain 의존을 빼고 Nav2 회귀 주석을 고친다 (#2172) #2176, docs(afternote,receiver): Nav3 이관 뒤 코드와 어긋난 KDoc·주석을 고친다 (#2170) #2171, chore(deps): bump the github-actions-updates group with 4 updates (#2139) #2138 조회). merge-order-stack-integrity.mjs 가 같은 필드를 이미 쓴다.

검증

• node --test .github/scripts/handle-merge-queue-dequeue.test.mjs 31건 통과(13건에서 늘었다).
• node --test .github/scripts/*.test.mjs 767건 중 766 통과, 1 skip, 실패 0.
• 실서버 조회만 하는 DRY_RUN 세 건:

#2123 ... 스택=2125 ... → requeue            (스택 밑단, merge-async 대상)
#2124 ... 스택=2125 ... → comment-stack-upper (base 가 refactor/1429-setting-repositories)
#2176 ... 스택=없음 ... → requeue            (비스택, GraphQL 대상)

• PUT .../pulls/2123/merge-async 에 무효 merge_action 을 보내 422 로 허용값(default, direct_merge, merge_queue)을 확인했다. 실제 큐 투입은 쏘지 않았다.

리뷰어에게

• 이 워크플로는 pull_request_target 이라 default branch 정의로만 돈다. 머지 전에는 새 경로가 한 번도 돌지 않고, 머지 뒤 스택 밑단 PR 이 방출되는 첫 사례에서 handle 잡 로그의 재투입(merge-async) → enqueued ... 줄과 mergeQueueEntry 생성을 본다.
• 실패 job 탐지 접두어는 여전히 PR 의 base 기준이다. 스택 위쪽 PR 이 큐에 들어간 run 이 이 저장소에 한 건도 없어 큐 브랜치 이름을 실측할 수 없었고, 위쪽 PR 은 자동 재투입을 막았으므로 이 PR 에서는 건드리지 않았다.

CI Test Plan

{"androidTest": {"mode": "none", "reason": "CI 정책 스크립트(.github/scripts)와 그 node 테스트만 바꿨다. Android 소스, androidTest, 경계 경로 변경 없음."}}

[Sadturtleman]

스택 밑단만 merge-async(merge_queue, sha 고정)로 재투입하고 결과를 폴링·live 재조회로 확인하는 흐름이 맞습니다. stack.baseRefName 필드도 실제 조회로 확인했습니다. 승인합니다.