Harness: durable background task lease, fencing, and cross-replica takeover

## Motivation

`WorkspaceTaskRepository` provides useful distributed read semantics: task records are persisted through `WorkspaceManager`, any node can read terminal status/result, pending deliveries are recoverable, and cross-node cancel writes `cancelRequested`. Local task execution is intentionally sticky to the originating node, however. If that node disappears while a task is `PENDING/RUNNING`, another replica cannot safely claim or resume it; the orphan sweeper eventually marks it failed.

This is honest current behavior, but it leaves enterprise background subagent work without failover/takeover semantics. Product hosts must not build a separate worker queue/lease coordinator around Harness tasks.

Observed against `e3a412ed2cc944e401da861c8d5e464b967724e9`. Real Redis fresh-JVM acceptance confirms terminal record/result/delivery recovery and user isolation; it does not prove running future migration.

## Proposed Harness-owned contract

Add optional durable execution ownership for recoverable task kinds, built into `TaskRepository`/task runners:

- persisted execution owner/worker id and lease epoch;
- lease expiry/heartbeat with server-side CAS or distributed guard;
- atomic claim/renew/release and fencing token;
- typed task kind and durable execution specification;
- retry/attempt/idempotency policy;
- takeover only for replayable task kinds;
- exactly one terminal transition and delivery;
- cancellation fenced against stale workers;
- orphan policy (`FAIL`, `RETRY`, `TAKE_OVER`, `REMOTE_QUERY`) expressed per task kind;
- typed events/readiness for claim, lost lease, retry, takeover and terminal outcome.

`LocalTaskRunSpec(Supplier)` is not serializable/replayable and should remain sticky/fail-on-orphan unless the caller supplies a stable executable resolver. `RemoteTaskRunSpec` can recover by persisted protocol identity/status and is a better initial target. Future native subagent task specs could persist agent declaration/session/task identity and rematerialize through `DefaultAgentManager`.

## Acceptance

1. Replica A submits a replayable task and stops after persisting RUNNING.
2. After lease expiry, replica B atomically claims with a higher fencing epoch and completes once.
3. A stale replica A cannot write heartbeat/result/cancel after losing ownership.
4. Terminal result produces one pending delivery; mark-delivered is idempotent across replicas.
5. Non-replayable local supplier is never silently re-executed; it reaches an explicit orphan failure.
6. Cancel racing with takeover has one deterministic outcome.
7. USER/session namespaces prevent cross-tenant claim/read.
8. Redis/MySQL/PostgreSQL backends pass the same CAS/fencing contract.
9. Product hosts need no task queue, worker registry, lease store or recovery scheduler.

This should compose with the existing heartbeat/orphan sweeper and `WakeupDispatcher`, not create a parallel task system.