fix: align ticket flat-state surfaces

.yoi/workflow/ticket-orchestrator-routing.md

@@ -21,7 +21,7 @@ Panel Queue / queued notification は、人間が Orchestrator に routing を
 ```text
 TicketCreate / TicketComment
   -> Ticket Orchestrator Routing Workflow
-  -> planning return / requirements sync / spike / implementation / review / blocked / close / pending
+  -> planning return / requirements sync / spike / implementation / review / blocked / close
   -> 必要に応じて他 Workflow へ接続
 ```
 
@@ -71,7 +71,6 @@ Orchestrator は以下を行う。
 - `TicketList`: routing 候補や関連 Ticket の確認。
 - `TicketShow`: 対象 Ticket の body / thread / artifacts / resolution 確認。
 - `TicketComment`: routing decision / intent packet / blocked reason / next question の記録。
-- `TicketStatus`: pending/open などの状態整理が明示的に許可された場合だけ使う。
 - `TicketWorkflowState`: `queued -> inprogress` acceptance、`inprogress -> done`、または concrete missing decision/information reason を伴う `ready|queued -> planning` に使う。
 - `TicketOrchestrationPlanQuery`: 対象 Ticket や関連 Ticket の ordering / blocker / conflict / waiting-capacity / accepted-plan 記録を読む。queued acceptance 前に必ず確認する。
 - `TicketOrchestrationPlanRecord`: Orchestrator が routing 中に project-relevant な ordering / dependency / conflict / capacity/waiting / accepted-plan decision を残す。これは queue reorder、自動起動、state 変更ではない。
@@ -88,7 +87,7 @@ Orchestrator は以下を行う。
   - `before` / `after` / `blocked_by` / `blocks` / `conflicts_with` / `do_not_parallelize` / waiting-capacity 記録がある場合、それを acceptance 判断の入力にする。記録は自動 scheduler ではないため、実際に進めるかどうかは Orchestrator が読んだうえで明示的に決める。
   - risk flags / risky domain がある場合は、IntentPacket に invariants / reviewer focus / escalation conditions を入れる。risk flag だけを `queued -> planning` の理由にしない。
 - concrete missing decision / information がある場合: `TicketWorkflowState` で `queued -> planning` を記録し、reason/body と `TicketComment` に不足項目、checked context、なぜ coder の implementation latitude では解決できないか、次の planning question/action を残す。既存の claimed live/restorable Intake/Planning Pod があり、既存通知経路が使える場合は同じ理由を通知する。
-- external action 待ちなど planning では解決しない blocker の場合: concise な理由を Ticket thread に記録し、queued のまま待つか、既存の Ticket state/state mechanism で明示的に defer/block する。
+- external action 待ちなど planning では解決しない blocker の場合: concise な理由を Ticket thread に記録し、必要に応じて attention / action-required frontmatter や `TicketOrchestrationPlanRecord` の blocker/waiting-capacity 記録で明示する。lifecycle 外の storage bucket を routing target にしない。
 
 Invariant:
 
@@ -214,7 +213,7 @@ Action:
 
 - 必要な判断・外部 action を短く書く。
 - `TicketComment` に blocked reason と next question を記録する。
-- 必要なら `TicketStatus` で pending に移す（許可がある場合だけ）。
+- 必要に応じて attention / action-required frontmatter や orchestration plan の blocker/waiting-capacity 記録で、待ち理由を current state とは別に表す。lifecycle 外の storage bucket へ移す route は使わない。
 
 ### `close_ready`
 
@@ -234,21 +233,6 @@ Action:
 - umbrella/progress-container Ticket を退役する close resolution では、関連作業がすべて完了したという意味ではなく container role を retired したことを明記し、完了済み concrete Ticket と残る follow-up Ticket / Objective を列挙する。
 - close 権限がない場合は merge-ready / close-ready dossier を親/人間に提出する。
 
-### `defer_pending`
-
-今は進めないが blocked ではない。
-
-条件:
-
-- 優先度・タイミングの理由で後回し。
-- 依存はあるが active blocker として扱うほどではない。
-- broad request が concrete implementable Ticket に分解され、Objective context や split decision record の作成待ちである。
-
-Action:
-
-- defer reason を `TicketComment` に記録する。
-- 必要なら `TicketStatus` で pending に移す（許可がある場合だけ）。
-
 ### `closed_or_noop`
 
 routing 不要。
@@ -395,7 +379,6 @@ IntentPacket が短く書けない場合、`implementation_ready` ではなく `
 - `review_needed` → reviewer Pod / review workflow
 - `blocked_action_required` → human / parent Orchestrator
 - `close_ready` → close workflow / maintainer decision
-- `defer_pending` → pending / Objective or split-decision follow-up management
 
 ## 完了条件