CLI: Bedrock, Vertex and Azure probe parity #51

Why

Child of #15. The app probe layer gained aws, gcp and azure kinds in #48 and vault wiring in #50, but cli/src/lib/probes.ts still only handles Anthropic and OpenAI-compatible providers. hoist keys probe bedrock, vertex and azure-openai fall through to 'No probe implemented', and the CLI probe command requires a vault key before dispatch, which blocks Bedrock (it reads the AWS env chain).

This child covers only CLI parity in the independent CLI release flow. App code is untouched.

Scope

• cli/src/lib/probes.ts - mirror the app probes: SigV4-signed Bedrock ListFoundationModels, Vertex publishers/google/models with project and region, Azure OpenAI deployments list. Same result shape and error wording as src/main/probes/.
• cli/src/index.ts - hoist keys probe: Bedrock probes without a vault key, Vertex reads provider:vertex:project and provider:vertex:region sibling vault entries, Azure resolves its endpoint from AZURE_OPENAI_ENDPOINT when no base URL is configured.
• cli/src/lib/vault.ts - sibling config secret id helper matching src/shared/secrets.ts.
• Tests with mocked HTTP only. No live provider keys.

Out of scope

• App changes in src/main/ or src/renderer/.
• Bedrock credential entry in the CLI. Bedrock still uses the AWS env chain.
• Live Bedrock or Vertex verification, which needs real cloud credentials and stays a reviewer note.

Acceptance criteria

• hoist keys probe bedrock reaches the aws probe without a vault key.
• Vertex probe errors sensibly without project and region, and uses stored sibling entries when present.
• Azure probe validates against the deployments endpoint with the api-key header.
• Mocked-HTTP tests cover the error and success paths and run in the CLI check.
• mise run ci:cli green.