test_remote_engine_start_refusal.bats: sync startのlock retake断定テストがmacOSで断続的に失敗する（2回中2回）

[kappaseijin4claude]

概要

tests/test_remote_engine_start_refusal.bats（upstream由来、PR #90でのupstream同期により導入）の以下のテストが、macOS runner上で2回中2回失敗しています。

not ok NNN sync start: a cleanup that cannot retake the lock says so and keeps the record (#817)
  (in test file tests/test_remote_engine_start_refusal.bats, line 375)
  `mkdir "$lock"' failed
  mkdir: <tmpdir>/teams/testteam/.config.lock: File exists

このテストはmkdir "$lock"を自身のsetupとして実行し、ロックディレクトリを新規作成できることを前提にしていますが、実行時に既にロックディレクトリが存在していたためmkdir自体が失敗しています。テスト名・症状から、直前の別テスト（同じ.config.lockパスを使う、同ファイル内の別テストである可能性が高い）がクリーンアップし切れずにロックディレクトリを残し、後続のこのテストが巻き込まれるテスト分離（test isolation）の問題と推測されます。

観測事実

PR	run	job	結果	再実行
#90（upstream同期本体）	32236810626	bats (macos-latest 2/4)	not ok 396	guarded rerunで解消（pass）
#87（team-work.sh修正、#90 merge後にrebase）	32240881039	bats (macos-latest 1/4)	not ok 397	再実行中

いずれもubuntu/windowsでは発生せず、macOS runner限定で2回とも再現しています。いずれもguarded single-job rerunで（少なくとも1件は）解消しており、hang/cancelではなく通常のtest failureです（Issue #88のCIハングとは別の症状）。

この差分との関連

このテストファイル自体、およびscripts/team-work.sh（本fork独自の機能）は無関係です。upstream由来のテストコードそのものに内在する問題と考えられます。

次のステップ（未着手）

• tests/test_remote_engine_start_refusal.bats内で、このテストの前後に同じ.config.lockパスを操作する他のテストがないか確認する。
• 直前のテストのteardown/cleanupが.config.lockディレクトリを確実に除去しているかを確認する。
• 再現性が高いようなら、テスト間で一意な一時ディレクトリを使うよう修正するか、upstreamへ報告する。

Codex復帰後、Issue #88と合わせて優先度を判断のうえ着手を検討してください。

[kappaseijin4claude]

訂正・精密化です。テスト本文（tests/test_remote_engine_start_refusal.bats:351〜）を読んだところ、当初の仮説（直前の別テストがロックを残す、というテスト分離の問題）は正確ではなさそうです。\n\n実際にはこのテスト自身の中で自己完結する競合の可能性が高いです:\n1. 367行目でこのテスト自身がremote.sh sync start testteamをバックグラウンド起動\n2. 369〜370行目でpidfileの出現を待つ\n3. 375行目で直後にmkdir "$lock"を1回だけ、リトライ無しで実行し、ロックが空いていることを前提にしている\n\n同ファイルの直前のテスト（170行目、fujibee#817）は、まさに「pidfile出現後もロック解放にはタイミングの揺れがある」ことを踏まえ、最大3秒（60回×0.05秒）ポーリングして確認する設計になっています。一方375行目のmkdirは単発です。pidfile書き込みとロック解放の順序・タイミングに何らかの揺れがあると、このテスト自身のstarterがまだロックを解放し切っていない瞬間にmkdirが実行され失敗する、という自己競合が起き得ます。\n\nクロステストのロック残留か、このテスト自身の自己競合か、実際にローカルで再現させないと確定できません。難易度・性質ともにIssue #88と同種（アップストリームの新規テストコードにある、並行処理まわりの微妙なタイミング問題）と判断し、こちらもCodex復帰後の着手対象とします。