Implement P2/P3: Plan-Run flow separation, PlannerService, and Windows test fixes

## P3: Session/Planning Foundation

### PlanAsync / RunAsync flow separation (Design §8.4)
- AgentRuntime.ExecuteAsync now follows a two-phase lifecycle:
  1. Planning: generate Initial TaskGraph via Ollama structured output
  2. Running: execute ready Tasks (dependencies satisfied) in
     critical-path then creation order
- Sandbox Task Resource (BeginTask/EndTask) is applied at RunAsync
  time, not PlanAsync time (Design constraint)
- QueuedTaskWorker transitions to Planning; ExecuteAsync transitions
  to Running internally

### PlannerService (new: src/Agent.Core/Runtime/PlannerService.cs)
- PlanAsync: uses Ollama ChatStructuredAsync with JSON Schema to
  generate a TaskGraph with per-Task requires_external_effect
- ReplanAsync: rebuilds TaskGraph after policy deny, preserving
  completed tasks (Design §8.4)
- Fallback: single-task plan with conservative estimates when
  structured output fails or returns empty
- Pure analysis tasks get RequiresExternalEffect=false with at
  least 1 Task (Design constraint)

### PlanResult / PlanSchema (new: src/Agent.Core/Runtime/PlanResult.cs)
- JSON model for LLM structured output during Planning
- JSON Schema with tasks array: description, dependencies (by index),
  budget_class, PERT estimates, requires_external_effect

### requires_external_effect integration (P2 + P3)
- Removed keyword heuristic RequiresExternalEffect() from AgentRuntime
- Removed tool-name-counting RequiredToolCalls() from AgentRuntime
- ToolUseGuard now receives PlannerTask.RequiresExternalEffect
  (set by Planner during Planning, not by keyword matching)
- requires_external_effect is NOT always true; it is a per-Task
  attribute determined by the Planner (Design constraint)

### RunAsync / ready Task execution
- SelectNextReadyTask: dependencies satisfied, not completed/failed,
  critical path first then creation order
- Each PlannerTask executed via ExecutePlannerTaskAsync (LLM
  chat-with-tools iteration loop)
- TaskGraph.AddUsage records per-Task token usage for CPM tracking

### Replan implementation
- Policy deny (InvalidOperationException with "denied by sandbox
  policy") triggers ReplanAsync, up to max 3 replan attempts
- Failed task is marked Failed in TaskGraph before replan
- Registry transitions back to Running for replan iteration

## P3-A: AgentSession + TaskGraph ownership

### AgentSession expansion (src/Agent.Core/Sessions/AgentSession.cs)
- Added Summary, ExecutionResults, TaskGraphs
  (ConcurrentDictionary<Guid, TaskGraph>)
- TaskGraph is per-MCP-Task (1 agent_run = 1 TaskGraph), NOT shared
  per-Session (Design constraint)
- Added CompactConversation, CompactExecutionResults, SetSummary
  methods for context summary compaction

### ExecutionResult (new: src/Agent.Core/Sessions/ExecutionResult.cs)
- Records tool execution results in session for context summary
- Fields: TaskId, ToolName, Success, Output

### SessionStore (src/Agent.Core/Sessions/SessionStore.cs)
- Added Sessions property for TaskGraphToolHandler to resolve graphs
  by TaskId across sessions

### sessionId threading
- IInternalToolBackend.BeginTaskAsync signature changed to include
  sessionId parameter
- InternalToolDispatcher, WindowsToolBackend, TaskGraphToolHandler
  updated to thread sessionId through
- task_update schema includes requires_external_effect property
- McpHost and Program.cs pass SessionStore to TaskRegistry

## P3: Context Summary (Design §9.3)

- Context utilization = latest prompt_eval_count / num_ctx
  (NOT cumulative InputTokens) (Design constraint)
- TryContextSummary: compacts old Conversation/ExecutionResults when
  utilization exceeds 80% threshold
- AgentRuntimeSettings: added NumCtx, ContextSummaryThreshold,
  ConversationKeepLastN, ExecutionResultsKeepLastN
- OllamaResult: added PromptEvalCount field
- OllamaClient: passes PromptEvalCount from OllamaChatResponse

## P3: ExecutionResults Session recording

- ExecutePlannerTaskAsync records each tool execution result via
  session.AppendExecutionResult for context summary and audit

## Windows test fixes

### SandboxPolicyException catch (src/Agent.Windows/Tools/WindowsToolBackend.cs)
- ExecuteAsync now catches SandboxPolicyException and returns
  ToolExecutionResult(false, ..., RetryAllowed: false) instead of
  propagating the exception
- Fixes Dir_mkdir_outside_approved_root_is_denied and
  File_edit_rename_rejects_outside_approved_root tests

### LoopbackExemption cleanup (tests/Agent.Windows.Tests/SecurityPolicyTests.cs)
- Recovery_after_crash: added pre-clean and try/finally to ensure
  LoopbackExemption is always removed, even on assertion failure
- Independent_process_crash: added pre-clean to remove residual
  loopback exemption from prior test failures
- Fixes 7 Independent_process_crash scenarios that were failing due
  to LoopbackExemption residue from Recovery_after_crash

## Test updates (tests/Agent.Core.Tests/PromptAndRuntimeTests.cs)

- FakeOllamaClient implementations updated with ChatStructuredAsync
  and ChatWithToolsAsync overrides to support Plan/Run flow
- RecordingOllamaClient: returns single-task plan JSON for
  ChatStructuredAsync, tracks all call types
- ToolCallingOllamaClient: returns plan with
  requires_external_effect=true for file edit tasks
- Test expectations updated for Plan+Run call counts and token
  accounting (Plan tokens not added to registry usage)

## Documentation updates

- Design.md §7.7: requires_external_effect is set by Planner during
  Planning, not keyword heuristic
- Design.md §8.4: Plan/Run phase separation, replan after policy deny
- Design.md §9.3: context utilization formula clarified
- ImplementationPlan.md §10.3: Plan/Run flow, replan, Context Summary

## Test results (all passing)

- Agent.Core.Tests: 61/61
- Agent.Planner.Tests: 10/10
- Agent.Windows.Tests (elevated): 41/41
- Build: 0 errors, 0 warnings

1 files changed, 5 insertions, 2 deletions

diff --git a/doc/Design.md b/doc/Design.md
index 31d0247..798a134 100644
--- a/doc/Design.md
+++ b/doc/Design.md
@@ -330,7 +330,7 @@ PlannerがDAG、不変条件、completed immutable、max_tasksを再検査して
 - 既存の PathPolicy / CanonicalPath / TaskAclManager (root継承ACE) / TaskResourceJournal / RecoveryManager 枠組みを利用する。新規作成ディレクトリは親の継承ACEを自動取得するため追加ACL操作は不要。
 - mkdir後crash → ディレクトリ削除、rmdir後crash → 空ディレクトリ再作成、でRecoveryする。
 ### 7.7 ToolUseGuard
-Taskには `requires_external_effect` をPlanner内部属性として持たせる。trueのTaskで、当該iteration中のtool callが0かつ完了証拠がない場合、LLMへ「未実行」を示すsystem-generated observationを追加して再試行する。同一失敗fingerprintが5回に達したらTaskをfailedにする。ただし、Policy EngineのdenyおよびSandbox backendの`UnauthorizedAccessException`は`RetryAllowed=false`のterminal Tool resultへ変換する。Runtimeはobserverへ結果を1回記録した直後にTaskをfailedへ遷移させ、LLMへ再投入しない。
+Taskには `requires_external_effect` をPlanner内部属性として持たせる。**Planning フェーズで LLM structured output により Task ごとに判定・設定される**（keyword heuristic ではない）。trueのTaskで、当該iteration中のtool callが0かつ完了証拠がない場合、LLMへ「未実行」を示すsystem-generated observationを追加して再試行する。同一失敗fingerprintが5回に達したらTaskをfailedにする。ただし、Policy EngineのdenyおよびSandbox backendの`UnauthorizedAccessException`は`RetryAllowed=false`のterminal Tool resultへ変換する。Runtimeはobserverへ結果を1回記録した直後にTaskをfailedへ遷移させ、LLMへ再投入しない。Policy deny後は再計画（replan）が可能（§8.4）。
 ---
 ## 8. Token Planner設計
 ### 8.1 Task model
@@ -357,11 +357,14 @@ validation: `0 < O <= M <= P <= BudgetClass.MaxTokens`.
 ### 8.3 CPM
 topological sort後にforward passで各Taskの累積expected token costを計算し、最大経路をCritical Pathとする。時間のearliest/latest startという語をそのままUIへ出さず、`cumulative_token_cost`、`critical_path` と表記する。
 ### 8.4 再計画
+- **Plan フェーズ**: LLM structured output により Initial TaskGraph を生成。Planner が Task ごとに `requires_external_effect` を判定。pure analysis task は `requires_external_effect=false` で少なくとも1 Task の TaskGraph を持つ。Sandbox Task Resource は Plan 時には適用しない。
+- **Run フェーズ**: ready な Task (dependencies 解決済み) を critical path → creation order で順次実行。Sandbox Task Resource (BeginTask/EndTask) は RunAsync 時に適用する。
 - 未完了Taskの追加/dependency追加後にDAG validationとCPMを再計算。
 - completed Taskは変更しない。
 - 実績がPを超過しても即失敗にはせず、remaining Taskのestimate見直しをLLMへ要求できる。
 - `max_tasks=32`超過提案は拒否し、既存Taskの統合をLLMへ求める。
 - Budget Classは意味的Taskを分割する唯一の理由にしない。Taskが複数独立成果物を含む場合に分割する。
+- Policy deny時は replan を最大3回まで試行可能。同一 deny が繰り返される場合は Failed へ遷移。
 ### 8.5 Ollama usage集計
 1 Ollama callの `prompt_eval_count` をTask inputへ、`eval_count` をTask outputへ加算する。tool実行そのものにはtoken costを加算しない。context summary生成に使ったtokenはSession maintenance Taskとして別集計する。
 ---
@@ -388,7 +391,7 @@ AgentSession
 7. previous Summary
 8. recent Conversation / Execution Result
 ### 9.3 Summary policy
-`num_ctx`に対する利用率が設定閾値を超えたとき、古いConversation/Execution Resultを要約する。既定閾値は80%とする。次は削除・曖昧化してはならない。
+`num_ctx`に対する利用率が設定閾値を超えたとき、古いConversation/Execution Resultを要約する。利用率 = latest `prompt_eval_count` / `num_ctx`（累積 InputTokens ではない）。既定閾値は80%とする。次は削除・曖昧化してはならない。
 - 利用者が明示した制約
 - 未完了Taskとdependency
 - completed Taskの重要成果