Idea: AI-assisted remote recovery-plan API for consensus node upgrade-diagnose (parked)

> **Status:** forward-looking idea, parked under #408 so it isn't lost. Not scoped for the current MVP — may be moved to a dedicated epic or the backlog later.

## Idea

Make `consensus node upgrade-diagnose` (#718) able to optionally talk to a **remote recovery-advisory API** that can be AI-powered: with explicit node-operator permission, upload (redacted) diagnostic artifacts and receive back a candidate **recovery plan**, which the operator reviews/edits and then runs via `consensus node upgrade-recover --plan ` (#717).

This is a natural extension of the existing diagnose→recover split: diagnose produces a plan, recover executes a reviewed plan, with a human-review gate in between. The *plan producer* is pluggable — local heuristics today, a remote/AI service tomorrow — without changing the executor or the review step. The AI never touches the node; it only proposes a plan a human approves.

## Hard constraints (non-negotiable for mainnet)

1. **Constrained, declarative plan schema — never free-form shell.** `upgrade-recover` must accept only a whitelisted action vocabulary (`restore-bak`, `restart-daemon`, `retry-infra-step`, …) with validated parameters. A hallucinated or tampered plan then cannot do more than the bounded action set allows. (This schema + validator is worth building regardless of AI — it is the core safety control.)
2. **Offline-first, AI-optional.** `upgrade-diagnose` must always produce a useful local diagnosis + the tier-2 escalation tarball with zero remote calls. The remote/AI path is an enhancement, never a hard dependency in the critical recovery path (nodes may be degraded, air-gapped, or the operator may decline upload).
3. **Explicit, redacting consent.** Uploaded artifacts (logs, `self-upgrade.yaml`, CR state) may contain hostnames, topology, or secrets-in-logs. Upload is opt-in per-incident, redacted, and the operator sees exactly what leaves the host.
4. **Governance.** Council node operators are independent. A phone-home in the recovery path raises data-residency, incident-time availability SLA, and air-gapped-deployment questions. Strictly opt-in and documented; offline path always available.

## AI framing (if/when built)

- Use AI as a **triage assistant**: classify the failure from logs+state and select/parameterize from a **vetted catalog of recovery plays**, with output constrained to the declarative plan schema.
- Avoid letting it invent novel repair steps — incident response wants determinism and reproducibility over creativity.

## Suggested sequencing

- Build the **constrained recovery-plan schema + `recover --plan` validator** first (foundation; useful even with a purely local producer).
- Keep #718 baseline = local diagnosis + plan emission (works offline).
- Layer the **remote/AI-assisted recovery-plan service** on top as separate scope — opt-in, redacting, offline-degradable.

## Relationship to existing tickets

- Extends `upgrade-diagnose` (#718) as an optional plan source.
- Consumed by `upgrade-recover --plan` (#717).
- Depends on the recovery-plan schema/validator (currently implicit in #717/#718 — may need its own story).