bats (ubuntu-latest): スイート完走後にハングし job timeout で cancelled になる

[orangewk]

症状

bats (ubuntu-latest) が、全テストの最後の1件が ok になった直後から出力が完全に止まり、job の execution time 上限（25分）で The operation was canceled. として強制終了する。

該当テストは、bats tests/ がアルファベット順に実行するファイル列の最後のファイル tests/test_watch_once.bats の最後のテスト:

ok 763 watch-once: skips a subscription held by another live session

このあと約14〜15分、一切の出力なしに固まる。job の post-cleanup ログには回収されなかった孤児プロセスが残っている:

Terminate orphan process: pid (...) (bash)
Terminate orphan process: pid (...) (sleep)

再現性

PR #29（run 29753842871）で 2/2 回、まったく同じ箇所で再現:

• 1回目: job 88391044663 — ok 763 の後、15:19:46 → 15:34:15 (JST 24:19:46 → 24:34:15) 無出力のまま cancelled
• 2回目（re-run後）: job 88505687184 — ok 763 の後、00:06:06 → 00:20:13 無出力のまま cancelled

同一テストの直後で毎回止まっているため、単発の infra flake ではなく決定的な hang に見える。

手がかり: 過去の類似事象

7/16 の docs/ADR のみの無関係な commit (run 29479826220) でも bats (macos-latest) が全く同じパターン（"exceeded the maximum execution time" → "The operation was canceled."）で失敗している。これを受けて aa72038（"ci: allow full bats suite to finish"）で timeout を 15→25分に引き上げたが、今回 ubuntu 側で再発した — 引き上げでは症状を隠しただけで根治していない可能性がある。

（このときの macOS hang がスイートのどこで止まっていたかは未確認。同じ「スイート末尾」だったかは要確認）

想定原因（未検証）

test_watch.bats / test_watch_once.bats は watch / watch-once のプロセスをバックグラウンド (&) で起動するテストを多数含む。いずれかのテストの teardown でバックグラウンドプロセス（またはその子プロセス）が完全には kill されず、標準出力/エラーの fd を握ったまま残っている可能性がある。bats 自身は全テストの実行を終えていても、GitHub Actions 側のログキャプチャ用パイプが EOF を受け取れずハングしていると考えられる。macOS/Windows で再現していない（今回のPRでは）のは、プロセスグループの扱いの違いか、たまたまタイミングの違いによるものかもしれない。

影響範囲

• scripts/drivers/types/codex/codex-bridge.js および tests/test_codex_bridge.bats（PR merge: upstream v1.1.10 #29 の hotfix 本体）には無関係。同PRでの bats (macos-latest) / bats (windows-latest)、および手元 Windows sandbox での test_codex_bridge.bats 単体実行（35/35 ok）はいずれも問題なし
• main は現在 branch protection / required status checks が未設定（bats (ubuntu-latest) を含め、workflow 内のコメントが謳う "REQUIRED status checks" は実際には enforce されていない）。そのためこの hang は現状 PR の merge を技術的にはブロックしていないが、CI の信頼性としては見過ごせない

TODO

• test_watch.bats / test_watch_once.bats の teardown を洗い出し、Linux で回収漏れになり得るバックグラウンドプロセスを特定する
• 7/16 の macOS hang が同じ末尾テストで起きていたか、過去ログを確認する
• 再現したら、該当テストの & 起動プロセスの kill 漏れ（プロセスグループ全体を殺せていない等）を疑う