fix: inherit the service starter CLI in managed runs

[version-1]

managed serviceで起動元Tasq CLIを継承する

Summary

tqdev service startで起動したorchestrator配下のagentが、PATH上の別バージョンのtqを実行し、tq updateによって親サービスを停止する問題を防ぎます。サービス起動元CLIを実行契約として継承し、agentのTasq操作とservice lifecycleの安全性を揃えました。

主な変更点:

• 起動元CLIの正規化済み絶対パスをTQ_EXECUTABLEとしてmanaged serviceへ伝播
• agentの初回・継続promptで"$TQ_EXECUTABLE"を使用し、旧構成ではtqへfallback
• managed run内のtq updateとtq service stopを状態変更前に拒否

やったこと

• TQ_EXECUTABLEとTQ_MANAGED_RUNの環境契約を追加
• service起動環境から同名の既存変数を除去し、起動元の値で一意に設定
• 既定task-work promptとcontinuation guidanceへ{{ tq.command }}を導入
• CLI拒否動作、環境伝播、managed/unmanaged promptの回帰テストを追加
• Symphony workflow contractを英語・日本語で同期更新

動作確認

• go test ./...
• git diff --check
• managed run内で updateと service stopが処理開始前に失敗することをテスト

レビュー & 動作確認 チェックリスト

• CLI同一性 - tqdev service start由来のpromptが"$TQ_EXECUTABLE"を使用すること
• 自己停止防止 - managed run内からサービス更新・停止が実行されないこと
• 後方互換性 - 環境契約なしの直接orchestrator起動ではtqへfallbackすること

推奨テスト計画:

1. PATH上に別のtqがある状態でtqdev service startを実行する
2. agent promptのTasq操作がTQ_EXECUTABLE経由になることを確認する
3. managed agentからtq updateまたはtq service stopを試し、拒否されることを確認する

その他気になることや相談ごと

TQ_MANAGED_RUNはagentの誤操作を防ぐ安全柵であり、悪意ある子プロセスに対するsecurity boundaryではありません。