Story: Recovery-plan schema + validator (shared by upgrade-diagnose/upgrade-recover)

Part of the consensus-node upgrade-lifecycle CLI commands (epic #408). Extracts the **recovery-plan schema + validator** that is currently implicit inside `upgrade-diagnose` (#718, the producer) and `upgrade-recover` (#717, the consumer) into its own explicitly-owned story.

## Why this is its own story

The recovery plan is an **executable artifact**: `upgrade-recover --plan` runs it against a root-privileged daemon. The schema is the load-bearing safety control for the whole diagnose→recover flow — and it is what makes any future remote/AI-assisted plan source (#719) safe. It should be owned and validated in one place, not duplicated across two command tickets.

## Scope

- **Declarative plan schema** (`upgrade-recovery-plan.yaml`): a constrained, versioned (`schemaVersion`) document describing an ordered list of recovery actions drawn from a **fixed whitelist vocabulary** — e.g. `restore-bak`, `restart-daemon`, `retry-infra-step` — each with typed, validated parameters. **No free-form shell / arbitrary commands.**
- **Validator** (shared Go package): parse + strict-decode + semantic validation (reject unknown `schemaVersion`, unknown action types, malformed/dangerous parameters). Reuse the existing manifest-validation idiom (cf. `pkg/manifests`). errorx errors.
- **Producer side (#718):** `upgrade-diagnose` emits plans that always conform to this schema.
- **Consumer side (#717):** `upgrade-recover --plan ` validates with this validator before executing, and executes ONLY whitelisted actions with validated params; an invalid plan is rejected with a clear error and no mutation.
- Document the schema (action vocabulary + examples) under `docs/dev/`.

## Acceptance criteria

- A plan with any action type outside the whitelist is rejected by the validator — never executed.
- Unknown `schemaVersion` or malformed parameters → rejected with a clear error, no host mutation.
- The same validator is used by both `upgrade-diagnose` (on emit) and `upgrade-recover` (on consume) — single source of truth.
- A hand-crafted (or hypothetical AI-produced) plan can do no more than the bounded action vocabulary allows.
- Unit coverage: valid plan passes; out-of-vocabulary action fails; bad params fail; unknown schemaVersion fails.

## Relationship to existing tickets

- Consumed by `upgrade-recover --plan` (#717) and produced by `upgrade-diagnose` (#718).
- Prerequisite safety foundation for the parked AI-assisted recovery-plan API (#719).