feat(TASK-028): escalation_timeout 0 waits indefinitely and is the default

Child escalations (coder plan approvals, deviation gates, user__* calls
from subagents) previously expired after the escalating agent's
escalation_timeout, defaulting to 300 s, and 0 timed out instantly. In
autonomous runs the orchestrator often could not reply within that
window, so approvals silently fell through to the best-judgment
fallback.

- Extract await_escalation_reply as the wait seam: 0 awaits the oneshot
  with no deadline; nonzero keeps tokio::time::timeout with the same
  timeout message. A dropped sender still resolves to the existing
  cancelled reply either way.
- DEFAULT_ESCALATION_TIMEOUT_SECS and default_escalation_timeout() -> 0,
  so graph agents (which inherit the default via from_graph) are covered.
- Document the new semantics in config.agent.example.yaml and drop the
  5-minute-timeout claim from the default spawn instructions.
- Tests: paused-clock unlimited wait (3600 s), nonzero expiry message,
  dropped-sender completion, default pin, and a grep pin that the stale
  timeout wording is gone from src/, assets/, and the example config.

Plan: PLAN-review-retry §C (D3).

src/config/agent.rs

@@ -889,7 +889,7 @@ fn default_summarization_threshold() -> usize {
 }
 
 fn default_escalation_timeout() -> u64 {
-    300
+    0
 }
 
 impl AgentConfig {

src/config/prompts.rs

@@ -200,7 +200,7 @@ pub(in crate::config) const DEFAULT_SPAWN_INSTRUCTIONS: &str = indoc! {"
     1. Read the child's question and options.
     2. If you can answer from context, call `agent__reply_escalation` with your answer.
     3. If you need the user's input, call the appropriate `user__*` tool yourself, then relay the answer via `agent__reply_escalation`.
-    4. **Respond promptly**; the child agent is blocked and waiting (5-minute timeout).
+    4. **Respond promptly**; the child blocks until answered — no timeout by default (`escalation_timeout` per agent).
 "};
 
 pub(in crate::config) const DEFAULT_JOB_INSTRUCTIONS: &str = indoc! {"