Harness: durable goal execution with budgets, progress protection, self-audit, and recovery

## Motivation

Harness provides a reliable bounded ReAct loop, persisted `TasksContext`/Todo tools, Plan Mode, permission/HITL, background tasks and middleware. It does not currently expose a durable long-running Goal contract comparable to high-quality coding agents that can continue toward an objective with a budget, detect repeated non-progress, self-audit completion and recover after interruption.

Applications can build such behavior outside Harness, but doing so duplicates loop, scheduler, state and completion ownership. A native contract would keep the existing ReAct/Harness runtime as the single owner.

Observed against `e3a412ed2cc944e401da861c8d5e464b967724e9`: `AgentState` persists `TasksContext`, but has no goal record, token/turn budget, repeat-detection or self-audit state seam.

## Proposed behavior-level contract

Add an optional Harness Goal execution mode built on the existing agent/state/middleware/task facilities. The exact API may differ, but it should provide a persisted record scoped by `(userId, sessionId, goalId)` with:

- immutable objective and creation identity;
- typed status (`ACTIVE`, `WAITING_FOR_APPROVAL`, `WAITING_FOR_EXTERNAL_RESULT`, `COMPLETED`, `FAILED`, `CANCELLED`, `BUDGET_EXHAUSTED`, `BLOCKED` or equivalents);
- consumed/remaining turn and token budget;
- current plan/todo snapshot references, key findings and next action;
- progress fingerprint/repeat counters and configurable non-progress policy;
- completion claim plus verifier/self-audit result;
- pending permission/tool/subagent/task identities already owned by Core/Harness;
- optimistic version and timestamps for restart/cross-replica recovery.

Execution should reuse the existing ReAct loop and typed events. A goal controller may schedule another bounded run only through an AgentScope-owned task/wakeup mechanism; it must not bypass HITL, tool permissions, workspace isolation, compaction or model fallback.

## Events and APIs

Useful public seams would include:

- start/resume/cancel/get/list goal operations with explicit runtime identity;
- typed `GoalStarted/Progress/Waiting/Completed/Failed/BudgetExhausted` events;
- middleware hooks for progress evaluation and completion verification;
- a deterministic recovery API that materializes the same goal after process/replica restart;
- readiness/capability facts when durable scheduling or cross-replica execution is unavailable.

## Acceptance

1. A multi-turn goal advances through Todo/Plan/tool/subagent work and completes only after verifier acceptance.
2. ASK pauses without consuming or bypassing the permission decision; approve/deny resumes the same goal.
3. External tool and background child waiting states remain non-terminal.
4. Repeated identical actions trigger a typed non-progress policy rather than an infinite loop.
5. Turn/token budget exhaustion is typed and persisted.
6. Cancel is idempotent and cleans up/orphans according to existing task policy.
7. Fresh runtime and distributed replica recover the same record exactly once.
8. Compaction preserves objective/current state/key findings/next action.
9. Product hosts need no GoalEngine, scheduler, budget store or completion database.

This should remain optional infrastructure above the stateless `ReActAgent` core and compose through Harness middleware/state/task seams.