feat(cli): explain delivery capabilities and readiness per destination #323

Problem

The CLI already exposes discovery, doctor capabilities and dry-run evidence, but users must combine several outputs to understand whether a particular destination can accept input and what evidence they can expect afterward. A reachable endpoint, successful submission, wake support and an explicit receipt are different facts.

Reference baseline: published Python v1.2.1, source f19f2b5e9ac17d392375507bc753548cdfc0e751. Existing doctor/dry-run behavior is implemented; this issue adds a clearer presentation, not a new transport or ACK capability.

Proposed scope

Provide an opt-in, per-destination explanation assembled from existing validated discovery/doctor/dry-run facts: selected agent and route, target availability, submission support, explicit wake support where proven, receipt/observation support, limitations and last observation time where meaningful. Begin with human-readable output; specify any additive machine-readable fields and CLI spelling before implementation.

Reason Network's delivery tiers are useful UX inspiration, but do not copy a blanket push classification or promise immediate consumption for Codex. Reference design.

Acceptance criteria

• Reuse existing capability and target-resolution logic; clearly distinguish observed facts, declared capability and unknown/unsupported conditions.
• Keep standalone list metadata-only. Do not introduce native-version probes, SSH connections or model/session activation beyond the explicitly selected command's existing contract.
• Show the actual selected host/device/home context without exposing credentials, message contents or receipt capabilities; sanitize human output.
• Separate submission, wake, injection observation, explicit receipt and task completion. A queue write, idle indication or native exit zero never becomes consumption/ACK evidence.
• Preserve ordinary output/exit compatibility, partial discovery errors and per-host failures. A readiness snapshot does not guarantee later delivery; actual send retains existing revalidation.
• Preserve unknown/no-automatic-resend behavior. Unsupported versions/routes must not silently fall back or gain capabilities.
• Cover unavailable/ambiguous targets, partial inventory, inactive Codex, unregistered Antigravity, supported versus unsupported handoff receipts and stale observations with bounded offline fixtures.
• Document the initial supported scope and examples in the existing four-language documentation.

Relationship and planning

Reuses completed doctor/addressing work (#45/#44) and complements #181 (handoff acceptance), #268 (storage contract) and #296 (existing-intent status view). It does not complete their remaining acceptance gates.

Priority P2; v1.3.0 planning candidate, first among the Reason-inspired UX slices. The owner's current research-first direction remains in effect; this issue does not schedule a release or authorize implementation, live experiments, operations or publication.