fix(directive): cancel orphaned planner and kick reconciler on goal update (#104)

Resolves the user-visible bug where editing a directive's goal mid-flight
shows "saved" but does not actually replan: the running planner kept emitting
add-step calls based on the OLD goal while a fresh planner was supposed to
take over, and the user had to wait up to 15s for the next reconciler tick
before any replanning even started.

## What was happening

PUT /api/v1/directives/{id}/goal already had two paths:
  - Small change + planner running → SendMessage interrupt + KEEP orchestrator.
  - Everything else → clear orchestrator_task_id and let phase_replanning
    spawn a new planner on the next 15s tick.

The "everything else" path cleared the directive's pointer to the planner
task but never cancelled the task itself. The task kept executing and could
race the new planner by adding more steps from the stale plan. Worse, those
new steps could push MAX(steps.created_at) past the just-bumped
goal_updated_at, suppressing phase_replanning entirely.

## Fix

1. New helper `try_cancel_running_planner()` (orchestration/directive.rs):
   sends `InterruptTask { graceful: true }` to the daemon owning the
   orchestrator task and marks the task `interrupted` in the DB. All errors
   are logged and swallowed so the goal update still completes.

2. update_goal handler calls the helper whenever it is about to take the
   "clear orchestrator_task_id" branch, so the orphaned planner stops
   producing stale-plan steps before its DB linkage is cut.

3. New `AppState::directive_kick` (tokio::sync::Notify) lets the handler
   signal the reconciler to run a tick immediately. The reconciler loop in
   server/mod.rs now selects between its 15s interval and the notify, so the
   user no longer waits up to 15s after editing a goal before replanning
   actually starts. update_goal calls `kick_directive_reconciler()` after
   the goal is persisted (both paths).

## Why not also loosen `get_directives_needing_replanning`

The query already covers the common cases once the orphan-cancel lands —
without a still-running orphan adding fresh steps, goal_updated_at reliably
exceeds MAX(steps.created_at) after a goal edit. Loosening the predicate
risked spurious replans for directives that legitimately have no steps yet
(those are handled by `phase_planning`).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions