Enhancement: gcloud-style config profiles (multi-account + per-profile zone defaults)

[Amperstrand]

Context

shc-compute / shc is positioned as a gcloud-compatible CLI (compute.py already mirrors gcloud compute instances create/list/delete). gcloud's config configurations lets users flip between named contexts (e.g. personal, work-prod, staging) — each with its own API key, default zone, default package. SHC has no equivalent: users juggle one SHC_API_KEY env var or a single config file.

For

• Multi-account UX. Users with separate personal/work SHC accounts (or dev vs prod projects) currently have to re-export SHC_API_KEY and re-set defaults each time. Named profiles eliminate that.
• Consistent with the gcloud positioning. compute.py already mimics gcloud's command shape; config configurations is the matching auth/profile primitive.
• Pairs with multi-zone reality. Now that there are two zones (Katy TX NVMe + Cherryvale KS Dev), a per-profile default order_form_id/module_group_id would prevent the validation error I hit this session (ordering an NVMe plan with the Dev VPS storefront).
• Cheap to add. A small ~/.config/shc/profiles.toml + shc config use <name> is a lowLOC change.

Against

• Niche. Most users have exactly one SHC account. Env var + a single config file covers the common case.
• Scope creep. The CLI's job is wrapping the API, not building a configuration manager. Adds surface area to test and document.
• Existing escape hatch. Power users can already use SHC_API_KEY + shell aliases / direnv to switch contexts.

Recommendation: low priority enhancement

Worth doing eventually (especially if multi-zone defaults become a frequent papercut), but not urgent. If implemented, default-profile selection should also carry the zone/order-form defaults so the NVMe-vs-Dev validation footgun goes away.