fix(builds): let the owner read a run a restart interrupted

[Eomdahyeon]

Closes #996

문제

재시작으로 중단된 run 은 mark_interrupted_runs 가 이벤트 저장소에만 run_failed(credentials_required)를 남긴다. 재시작 뒤에는 레지스트리가 비어 있고 매니페스트도 없어서 GET /builds/{run_id} 와 GET /builds/{run_id}/events 가 모두 404 다. 빌드를 폴링하던 클라이언트는 "다시 제출하라" 대신 "그런 run 은 없다"를 받는다.

변경 내용

• 제출자를 남긴다. 이벤트 저장소(_build_events.sqlite)에 run_submissions(run_id, owner_id, created_by, submitted_at) 테이블을 추가하고, 비동기 제출 시 run_submitted 이벤트와 함께 기록한다. 소유자는 지금까지 메모리의 레지스트리와 (끝난 뒤의) 매니페스트에만 있었다. 테이블은 CREATE TABLE IF NOT EXISTS 로 추가되고 기존 행·스키마 버전은 건드리지 않는다.
• 상태 조회. build_status: 레지스트리 → 매니페스트 → 이벤트 저장소의 종료 이벤트. 중단된 run 은 status: failed, error(이벤트 메시지), code: credentials_required, created_at(제출 시각), updated_at(실패 시각)으로 답한다. 정상 종료(run_finished)는 여기서 답하지 않는다 — 그 경우의 근거는 매니페스트다.
• 권한. check_active_run_access: 매니페스트 → 레지스트리 → 제출 기록으로 소유권을 판정한다. 다른 사용자는 없는 run 과 같은 답(멀티유저에서 404)을 받는다.
• 계약 1.77.0 → 1.78.0 (additive): BuildJob.code(optional, credentials_required), BuildJob 설명. CHANGELOG [Unreleased] Fixed.

한계

• 이 버전 이전에 제출된 run 은 제출 기록이 없어서 재시작 뒤 여전히 404 다. 기존 run 을 소급해 채울 근거(소유자)가 디스크에 없다.
• mark_interrupted_runs 가 실패 이벤트를 남기는 조건은 바꾸지 않았다.

#1008 과의 관계

#1008 은 routes/_guards.py 의 check_existing_run_access docstring 과 routes/builds.py 를 고친다. 이 PR 은 같은 파일의 check_active_run_access 를 고치고 routes/builds.py 는 건드리지 않는다. 겹치는 것은 계약 버전 줄과 CHANGELOG 뿐이다 — 나중에 머지되는 쪽이 버전을 하나 올리면 된다.

검증

• tests/unit/test_interrupted_run_status.py: 소유자는 failed + code 를 받는다 / 소유자는 run_failed 이벤트를 본다 / 다른 사용자는 두 경로 모두 없는 run 과 같은 404 이고 본문에 사유가 없다 / 제출된 적 없는 run 은 404 / 제출 기록은 한 번만 쓰인다.
• 전체 스위트 1회: 1 failed, 4429 passed — 실패한 하나는 이 PR 의 새 테스트였다. 첫 번째 프로세스의 worker 를 테스트 도중에 풀어 줘서 그 worker 가 이벤트를 더 쓰는 경합이었고(실제 재시작에서는 그 프로세스가 죽는다), worker 를 테스트가 끝날 때까지 막아 두도록 고쳤다. 고친 뒤에는 이 파일과 test_ephemeral_credentials.py 를 3회 반복 실행해 모두 통과(19 passed ×3)했고, 전체 스위트를 다시 돌리지는 않았다.
• check_contract_compat.py: 1.77.0 -> 1.78.0 호환. ruff, mypy 통과.

🤖 Generated with Claude Code

[yeongseon]

리뷰 (코멘트 — 테스트 잡이 아직 도는 중이라 승인은 녹색 확인 뒤에).

diff 를 읽었습니다. 방향과 구현 모두 타당합니다: 제출자를 이벤트 저장소에 남기고, 상태 조회를 레지스트리 → 매니페스트 → 종료 이벤트 순으로 내리고, 정상 종료는 매니페스트에만 맡긴 것. 다른 사용자가 없는 run 과 같은 답을 받는다는 것을 테스트가 본문까지 확인합니다. 본문에 적은 경합 수정도 설명과 일치합니다.

짚어 둘 것 하나 (이 PR 을 막지는 않음): check_existing_run_access 는 제출 기록을 보지 않습니다. 재시작으로 중단된 run 의 run_id 는 매니페스트도 레지스트리도 없어서 "새 run" 으로 통과하므로, 다른 사용자 B 가 같은 id 로 제출할 수 있습니다. 그러면

• record_submission 은 INSERT OR IGNORE 라 소유자는 A 로 남고,
• B 의 작업이 레지스트리에 있는 동안 B 는 그 run_id 의 이벤트 — A 의 run_submitted/run_failed 포함 — 를 읽고,
• B 의 작업이 다시 중단되면 제출 기록상 소유자인 A 가 B 의 실패를 읽습니다.

id 재사용 자체는 이 PR 이전에도 가능했지만, 이제 판정할 기록이 생겼으니 check_existing_run_access 도 제출 기록을 보게 하면 닫힙니다. #1008 과 같은 함수라 그쪽이 머지된 뒤 후속으로 하는 편이 충돌이 적습니다.

계약 버전은 본문대로 #1009 와 겹칩니다(둘 다 1.78.0) — 나중에 들어가는 쪽이 올립니다. 로컬에서 테스트를 돌리지는 않았습니다.

[Eomdahyeon]

CI 실패 원인을 찾아 고쳤습니다 (7df0ed4).

tests/unit/test_json_array_reader.py::test_many_small_elements_still_stream 가 assert 1214043 < 1048576 로 실패했는데, 이 PR 의 restarted fixture 탓이었습니다. teardown 이 gate 를 풀고 shutdown(wait=False) 만 불러서, 풀려난 첫 서비스의 워커가 다음 테스트들 뒤에서 빌드를 계속 돌렸고, tracemalloc 은 모든 스레드의 할당을 세므로 그 테스트의 peak 에 섞였습니다. 이제 teardown 이 워커 종료를 기다립니다.

확인: 고치기 전 fixture 로 두 파일을 함께 돌리면 3회 모두 1 failed, 22 passed, 고친 뒤에는 3회 모두 23 passed.

check_existing_run_access 가 제출 기록을 보지 않는다는 지적은 맞습니다. 말씀대로 #1008 머지 뒤 후속으로 하겠습니다.