hardening: git index.lock 강제 삭제가 살아있는 락을 지울 수 있다 — 소유 기반 회수로 대체

[pdw96]

문제

src/main/core/workspace/git.ts 의 ok() 재시도 루프는 2회차 이후 index.lock 을 무조건 삭제한다.

if (attempt >= 1 && existsSync(lock)) {
  try { rmSync(lock) } catch { /* 다음 시도에서 재확인 */ }
}

발동 조건은 ⓐ락 계열 stderr 매칭 ⓑ2회차 이후(누적 ~450ms 대기) ⓒexistsSync 셋뿐인데,
어느 것도 그 락이 stale 하거나 Fleet 소유임을 증명하지 못한다. 사용자의 IDE 나 터미널에서
돌아가는 git add/git status 는 큰 레포에서 450ms 를 쉽게 넘기고, 그 살아있는 락을 지우면
경쟁 인덱스 writer 가 허용되어 staged 상태가 유실될 수 있다.

Codex 가 PR #282 에서 P1 으로 지적했다(pull/282#discussion — workspace/git.ts:25).
코드 자체는 #282 이전부터 있던 것이고, #282 는 그 사실을 문서화만 했다.

왜 그냥 삭제를 없애면 안 되나

이 회수가 존재하는 이유는 실재한다 — Fleet 이 스폰한 편집 에이전트 CLI 가 취소(kill-tree)나
크래시로 죽으면 index.lock 이 남고, 이후 Fleet 의 모든 git 조작이 영구히 실패한다.
그냥 제거하면 그 시나리오에서 사람이 손으로 지워야 한다.

제안 방향 — 「시각」이 아니라 「소유」로

락 나이·재시도 횟수 같은 간접 신호는 전부 휴리스틱이다(git 은 index.lock 에 소유 PID 를
기록하지 않는다). 대신 소유를 구성적으로 아는 지점에서 회수한다:

• Fleet 이 자기 자식 프로세스 트리를 죽인 직후, 그 워크트리에 대해서만 잔존 락을 회수한다
  (process/kill-tree.ts 경로 — 그 시점엔 「우리가 방금 죽인 프로세스가 유일한 후보」가 성립).
• 재시도 루프 안에서는 삭제하지 않고 bounded backoff 후 정직하게 실패한다.
• 회수하지 못한 잔존 락은 조용히 지우지 말고 사용자에게 보이는 상태로 올린다(진단 가능성).

이 방향은 [[#251]] 워크벤치가 락·리스에서 채택한 원칙(「연령·신원은 소유 증거가 아니다」)과 같다.

완료 조건

• ok() 의 무조건 rmSync(index.lock) 제거
• 소유 기반 회수 경로 신설 + 테스트(살아있는 락은 안 지운다 / 우리 자식 사후엔 지운다)
• workspace/git.ts 의 ApprovalGate 예외 근거 절에서 「규칙 미충족 · 추적 중」 표기 해제
  (현재 scripts/approval-gate-exceptions.test.ts 가 강제하는 열거에 이 모듈이 들어 있다)

[pdw96]

범위 축소 — 「삭제 제거」는 PR #282 에서 선반영됐다 (99f957f).

두 리뷰어(Codex 2R P1 · CodeRabbit Major)가 독립적으로 같은 결론을 냈고, 조사 중 이 코드의 안전
근거가 이미 거짓임을 확인해서 #282 에서 바로 제거했다 — deploy/docker-compose.yml 이 ttyd 와
/workspace 를 공유하므로 「오케스트레이터 순차 실행」 전제가 출하 형상에서 성립하지 않는다.

현재 상태: ok() 는 백오프 재시도만 하고, 소진하면 락 경로를 실패 메시지에 실어 정직하게 실패한다.
「외부 락을 삭제하지 않는다」 회귀 테스트 동반.

이 이슈에 남는 범위 = 잃어버린 자동 회수의 복원:

• Fleet 이 자기 자식 프로세스 트리를 죽인 직후(process/kill-tree.ts 경로), 그 워크트리에 한해
  잔존 락을 회수한다 — 그 시점에만 「우리가 방금 죽인 프로세스가 유일한 후보」가 성립한다
• 회수하지 못한 잔존 락은 조용히 지우지 말고 사용자에게 보이는 상태로 올린다
• 완료 조건에서 「ok() 의 무조건 rmSync 제거」·「근거 절 미충족 표기 해제」는 완료로 이관