[ci][tests] CI の runner は legacy_tiocsti=0 で TIOCSTI の拒否を測れず、判定もログに残らない #677

背景

#667 は、隔離の中の子が制御端末へ TIOCSTI で入力を注入できる問題を、子の setsid() で閉じました（PR #674、develop 739c441c）。試験 isolated_child_cannot_inject_into_the_controlling_terminal は、まず正の対照（制御端末を持つ普通の子）で注入が成り立つことを確かめ、そのうえで隔離された子が注入できないことを測ります。正の対照が成り立たない環境では UNVERIFIED と記録し、試験は pass します。

PR #674 の CI（GitHub-hosted の Ubuntu 24.04）では、正の対照の TIOCSTI も EIO（5）で拒否されました（workspace/tmp/1007/wave1/results/L-52/pr.md:22〜:23）。kernel の dev.tty.legacy_tiocsti=0 のとき、CAP_SYS_ADMIN を持たない TIOCSTI は一律に EIO になります。注入の拒否を測ったのは、leader の Docker（legacy_tiocsti=1）と macOS だけです。
関連：#667

問題

• P1：CI では TIOCSTI の試験が毎回 UNVERIFIED になり、注入の拒否を CI で一度も測っていません。仕組み（子が自分の session を持つこと）は別の試験で CI でも固定していますが、kernel が実際に注入を拒否するかは、CI では回帰として検出できません。
• P2：判定（BLOCKED・UNVERIFIED）が CI で読めません。
  • pass した試験の出力は cargo test が捕まえるので、ログに出ません。
  • $GITHUB_STEP_SUMMARY への記録は job summary にだけ出ますが、gh・REST API では読めません（results/L-53/667.md:34）。
  • このため、UNVERIFIED が続いていることを機械的に確かめられません。stdin・devnull-fd・terminal-read の probe の判定も同じです。

根拠（develop 739c441c）

• tests/issue502_os_sandbox_write.rs:1313：bounded_child_runs_in_its_own_session_and_process_group。sid = pid を確かめ、CI でも走る。
• tests/issue502_os_sandbox_write.rs:1394：正の対照が成り立たないと UNVERIFIED にする。
• tests/issue502_os_sandbox_write.rs:1447：record_unverified（stdout と summary に書く）。
• tests/issue502_os_sandbox_write.rs:1456：record_tiocsti_step_summary（$GITHUB_STEP_SUMMARY にだけ書く）。
• tests/issue502_os_sandbox_write.rs:1478：外側の試験。UNVERIFIED でも pass する。
• .github/workflows/ci.yml:36〜:58：commandagent-guardrails の job（ubuntu-latest、bash scripts/ci.sh）。
• scripts/ci.sh:9：cargo test --all-targets。

対処の方向

1. CI で TIOCSTI を測る：commandagent-guardrails の試験の前に、sudo sysctl -w dev.tty.legacy_tiocsti=1 の step を足す。
   • GitHub-hosted runner は使い捨ての VM で、sudo を使えます。この sysctl が runner の kernel で書けるかは未確認なので、最初の PR で確かめます。
   • 書けない場合は、macOS の runner の job を検討します（macOS では注入を測れることを確かめてあります）。
   • 取らない手段：
     • container の中で設定する案は、sysctl に namespace がないので効きません。
     • root や CAP_SYS_ADMIN で流す案もとりません。kernel は CAP_SYS_ADMIN を持つ呼び出し元には制御端末の確認を飛ばすので、負の対照も注入できてしまい、正しく測れません。
2. 判定を CI で読めるようにする：
   • probe の判定を $RUNNER_TEMP などのファイル（新しい環境変数で場所を渡す）にも書く。
   • 試験の後の step で、そのファイルを cat してログに出す。UNVERIFIED のときは ::warning:: の annotation を出す（check-runs の annotations API で読める）。
3. UNVERIFIED の扱いの選択：1 が CI で確かめられたら、CI では TIOCSTI の UNVERIFIED を失敗にするか（たとえば COMMANDAGENT_REQUIRE_TIOCSTI=1 のときだけ）を PM・利用者が決める。手元や legacy_tiocsti=0 の環境で UNVERIFIED を許すことは変えない。
4. .github/workflows/ を変えるので、harness・CI の変更として PM の承認を受ける。

受け入れ条件

• CI の job ログ、または annotation で、TIOCSTI の判定が読める（BLOCKED か UNVERIFIED と理由、legacy_tiocsti の値）
• CI で legacy_tiocsti=1 にでき、TIOCSTI の試験が BLOCKED になる（できない場合は、その証跡と代わりの手段を書いた）
• 二点測定：CI と同じ設定の環境で、setsid を外した写しでは TIOCSTI の試験が FAILED になる（変更は使い捨ての写しだけ）
• 手元（macOS、legacy_tiocsti=0 の Linux）での試験の扱いは変わらない
• 検証・受入・証跡のゲートを緩めていない。UNVERIFIED を黙って成功扱いにする経路を増やしていない

対象ファイル

• .github/workflows/ci.yml
• scripts/ci.sh
• tests/issue502_os_sandbox_write.rs