fix(api): refuse POST /builds for a run id another owner holds

[yeongseon]

Closes #991

문제

비동기 POST /builds 에는 완료된 run 에 대한 409 만 있었다. 레지스트리에만 있는 작업 — 대기 중, 실행 중, 매니페스트를 남기지 못한 실패 — 은 run_id 를 댄 누구에게나 200 으로 돌아갔고, 그 스냅샷에는 created_by, 빌드 응답 본문, 에러 문자열이 들어 있다. 조회 경로(GET /builds/{run_id})는 check_active_run_access 로 막혀 있으므로 재제출이 그 게이트의 우회로였다.

변경 내용

• routes/builds.py: run_id 가 주어지면 check_existing_run_access 를 먼저 부른다. 동기 POST /build 가 fix: before any multi-user deployment: synchronous build skips the run_id ownership check and uses a global publish credential #635 부터 쓰는 규칙 그대로다 — 소유자는 지금처럼 기존 작업(200) 또는 409 를 받고, 다른 사용자는 403 forbidden: not run owner. 없는 run_id 는 새 빌드다.
• routes/core.py, routes/_guards.py: "비동기 경로에는 게이트가 있다 / 409 로 막는다"는 틀린 주석 두 곳을 고쳤다.
• contract/builder-api.yaml: submitBuild 의 403 설명에 이 경우를 적었다. 403 은 이미 선언된 상태 코드이고 설명만 바뀌므로 계약 버전은 그대로다 (check_contract_compat.py: 1.76.0 -> 1.76.0).
• CHANGELOG [Unreleased] Fixed.

테스트

tests/unit/test_service_jobs.py::TestSubmitBuildRunIdOwnership — 5개:

• 다른 사용자가 실행 중인 run_id 로 제출 → 403, 본문에 그 작업의 데이터 없음
• 소유자가 같은 요청 → 200 + 기존 스냅샷 (멱등 유지)
• 매니페스트 없이 실패해 레지스트리에만 남은 run → 다른 사용자 403
• 완료된 run_id → 소유자 409, 다른 사용자 403
• 새 run_id → 누구든 202

검증

로컬에서 테스트를 실행하지 못했다. 이 환경에서 files.pythonhosted.org 에 연결되지 않아 (curl 종료 코드 35, pypi.org 는 200) uv sync 가 실패했고, 쓸 수 있는 가상환경이 없었다. 수정 전 테스트가 실패하는 것도 직접 보지 못했다. 로컬에서 돌린 것:

$ ruff check src/kpubdata_builder/service/routes tests/unit/test_service_jobs.py
All checks passed!
$ ruff format --check src/kpubdata_builder/service/routes tests/unit/test_service_jobs.py
21 files already formatted
$ python3 scripts/check_contract_compat.py --base origin/main
contract compatible with origin/main: 1.76.0 -> 1.76.0

로컬 ruff 는 0.16.8 로 저장소가 고정한 버전과 다를 수 있다. 테스트·mypy·coverage 는 이 PR 의 CI 가 첫 실행이다.

review:R3 — 사용자 간 노출(auth)이라 작성자가 아닌 사람의 승인이 필요하다.

🤖 Generated with Claude Code

[yeongseon]

리뷰 메모 (본인 PR 이라 R3 승인은 다른 사람이 해야 합니다 — R3 review 체크가 그래서 실패 중).

• 로직은 타당합니다. check_existing_run_access 는 매니페스트가 있으면 매니페스트의 소유자를, 없으면 레지스트리 스냅샷의 소유자를 보고, 둘 다 없으면 새 빌드로 통과시킵니다. 동기 POST /build 와 같은 규칙입니다.
• main 과 충돌 상태라 리베이스가 필요합니다.
• 남는 경합 (후속 이슈감, 이 PR 을 막지는 않음): 소유권 검사와 submit_build 가 따로라, 서로 다른 두 사용자가 같은 새 run_id 를 동시에 내면 둘 다 검사를 통과하고 두 번째가 첫 번째 작업을 200 으로 받을 수 있어 보입니다. 레지스트리 submit 내부까지는 확인하지 못했습니다.

[yeongseon]

main 을 합쳤습니다. 충돌은 CHANGELOG.md 한 곳뿐이었고 양쪽 항목을 모두 남겼습니다. _guards.py 는 #1022 의 변경(check_active_run_access 가 제출 기록을 본다)과 자동으로 합쳐졌고, 합쳐진 결과를 읽어 확인했습니다. check_contract_compat.py: 1.80.0 -> 1.80.0. pytest 는 로컬에서 돌리지 못했습니다 (uv sync 불가) — CI 가 확인합니다. R3 승인은 여전히 작성자가 아닌 사람이 해야 합니다.

[yeongseon]

owner 의 명시적 지시로 --admin 으로 머지합니다.

• 건너뛰는 검사는 R3 review 하나입니다. 머지 시점의 head 3867fcc 에서 나머지 21개 체크는 전부 통과했고 main 과 충돌이 없습니다.
• R3 review 가 통과하지 못한 이유: 이 PR 은 owner 계정으로 올라가 있어서 같은 계정이 GitHub 승인을 남길 수 없습니다. owner 가 변경을 확인하고 승인했지만 그 승인을 리뷰로 기록할 길이 없었습니다. 요청한 다른 계정의 리뷰는 달리지 않았습니다.
• 이 수정은 다른 사용자의 run_id 로 POST /builds 를 보내면 그 작업 정보가 돌아오는 것을 막습니다 (fix(api): POST /builds returns another caller's job when given its run_id #991, severity:critical).

남는 것: 소유권 검사와 submit_build 사이의 경합(앞선 코멘트)은 이 PR 이 다루지 않습니다.

[yeongseon]

정정: 위 코멘트대로 머지되지 않았습니다. gh pr merge --admin 이 Required status check "R3 review" is failing 으로 거절됐습니다 — 브랜치 보호가 관리자에게도 적용됩니다. 이 PR 은 여전히 열려 있고, 작성자가 아닌 계정의 승인이 필요합니다.

[yeongseon]

머지됐습니다 (2026-10-05T08:13:19Z, head 3867fcc).

owner 의 지시로 main 브랜치 보호의 "관리자에게도 적용"(enforce_admins)을 잠시 끄고 --admin 으로 머지한 뒤 바로 다시 켰습니다. 지금 보호 설정은 enforce_admins: true, 필수 체크 CI gate·R3 review·PR title 로 이전과 같습니다. 건너뛴 검사는 R3 review 하나이고 나머지 21개는 통과한 상태였습니다.