chore(insurance): track Archera pkg/insurance consumer integration (go, platform, CLI, MCP) #786

Tracking: Archera integration consumers of pkg/insurance

The Archera insured-commitment comparison contract pkg/insurance is merged in cloud-commitments-go (#285, closes go#284), and nothing consumes it yet. This issue tracks wiring it into each consumer. These issues cover scope only; the implementation PRs come later.

Dependency order

1. go#311 (CHANGELOG) has no dependencies and should land before the first consumer pins pkg/insurance.
2. Platform (feat(insurance): consume pkg/insurance for an explicit Archera comparison (backend, API, config, UI) #785) goes first. It settles the shared config names, the error wording for "not configured" and "incomplete", and the response DTO conventions (unknown means null, premium included, no currency).
3. CLI (cli#2156) and MCP (mcp#48) follow and reuse the decisions from feat(insurance): consume pkg/insurance for an explicit Archera comparison (backend, API, config, UI) #785. They can run in parallel with each other.
4. Every consumer bumps github.com/LeanerCloud/cloud-commitments-go/pkg to a commit that contains fix(frontend): post-exchange refresh drops the RI account scope and skips reshape recs #285 (73d3366 or later). Today platform pins a9a426224031, and CLI and MCP pin 90e61e668b99; both predate pkg/insurance.

Shared configuration (all default off)

Shared rules:

• With no config, the surface is disabled and makes no outbound call.
• With an explicitly requested action and incomplete config, the result is a sanitized error naming the missing setting, never a silent success.
• No implicit Archera calls on startup, or on the recommendation or purchase paths.
• The key is never in flags, tool arguments, browser state, response JSON, audit records or logs.

Cross-cutting acceptance (each consumer)

• Offline tests traverse the real production composition (config, insurance.NewClient, documented GET, decode, consumer output) through an injected transport to httptest, using recorded or synthetic official-schema responses and a synthetic key and IDs.
• No live calls to api.archera.ai, and no purchases, binding or customer submissions.
• Unknown money is rendered as unknown, never 0. Premium-inclusive totals are kept, and the missing currency field is stated.
• AssessProductSupport is shown per product, with unknown as the default and never shown as supported.
• The existing mandatory Archera disclosures stay visible. No "insured" or "guaranteed" claim beyond the contract.
• The key does not appear in captured output. Each test greps for the synthetic key.
• Process: each plan gets 2 review passes, and each PR gets a fresh independent reviewer.

Contract questions to settle before planning

1. Env prefix: shared unprefixed ARCHERA_* in CLI and MCP, or the CLI convention CUDLY_ARCHERA_*? The proposal is unprefixed for all three, so documentation matches across repos.
2. Platform key: ARCHERA_API_KEY_SECRET (a secret reference resolved through internal/secrets / SECRET_PROVIDER, matching the *_SECRET convention), plus a plain ARCHERA_API_KEY for local dev only, or not?
3. MCP default-off: register the tool only when config is complete, or always register it and return "not configured"?
4. Platform tenancy: one global Archera org and plan per deployment (MVP), or a per-cloud-account mapping?
5. Filters: do consumers pass ContractTerms, PaymentOptions and LineItemIDs through, or use the documented defaults only?
6. Permission: is the platform endpoint gated by the existing recommendations read permission, or a new view:insurance?
7. Unknown products: is a product outside the documented eligibility rows hidden, or shown as "unknown"? The proposal is to show it as unknown and never hide it.
8. Vendor errors: surface 429 Retry-After to the user as is. The client never retries; confirm that consumers also must not add automatic retries.