[recovery-daemon] Typed diagnosis→recovery contract + recovery-run ledger (C4)

Parent: Epic #13874. Graduated from Discussion #13871 (Axis C → C4).

Problem / scope

The bridge between the diagnostics daemon (#13860, the producer) and the recovery daemon (the consumer): a typed diagnosis→recovery event + a recovery-owned, persisted recovery-run ledger. Loose SSOT ownership, strong recovery-run correlation — NOT shared mutable health state (C2/C3 rejected by ADR-0025 detect≠actuator + SSOT-each).

Acceptance Criteria

• Typed diagnosis event carries: recoveryClass ∈ {contention,crash,config-drift,exhaustion,external-load,ambiguous}, confidence, evidence facts, and targetIdentity: {kind: 'supervised-task'|'compose-service'|'deploy-target', id} (graduation AC-2 — deterministic B0-vs-external routing, no inference).
• Reuses the existing watchdog alarm envelope (recordTaskOutcome details + the #13818/#13859 one-shot latch + {symptom,…}) — NOT a parallel taxonomy (AC-7).
• Recovery-run ledger (recovery-owned, persisted, survives orchestrator restart): one entry per recoveryRunId with rung/attempt/backoff state.
• Retention cap on the ledger mirroring remRunRetentionLimit (graduation AC-5) — no unbounded growth.
• Re-observe handshake interface: recovery asks diagnostics for a fresh observation after cooldown before escalation/success.

Contract Ledger

• Adds: the typed diagnosis→recovery contract types + the recovery-run ledger store (pattern: remRunStateStore).
• Reuses: recordTaskOutcome, the #13818 watchdog latch, the durable harness-state store (ADR-0009 layer).

Sequencing

Depends on the diagnostics-producer side (#13860). The 6-class taxonomy is converged (Discussion #13871). Privilege-free.