ux(settings): create-override modal for Azure and GCP accounts (V2 of #106)

[cristim]

Summary

The "Add override" create modal landed in #106 is AWS-only by design. Non-AWS accounts (Azure, GCP) keep the original read-only empty-state text and gain neither the Add button nor the auto-open. The relevant gate is the provider === 'aws' check at the top of loadOverridesPanel in frontend/src/settings.ts.

This V1 boundary was deliberate — Azure has different payment options (upfront/monthly), GCP has no payment concept at all (just monthly), and the per-service term/payment options live in commitmentOptions.ts keyed per provider. Wiring those into the override modal cleanly is its own piece of work.

Why now

• Once issue ux(settings): account override UIs should reuse commitmentOptions validity rules (e.g., RDS 3yr no-upfront) #107 lands, AWS override UIs reuse commitmentOptions.ts's validity rules. The same hooks (getValidPaymentOptions, getValidTermOptions, isValidCombination) already exist for azure and gcp keys — we just need to wire the modal to consult them per provider.
• Without this, Azure/GCP accounts have no UI affordance to create per-account overrides at all — same dead end the AWS panel had pre-feat(settings): create-override modal for AWS account overrides (closes #104) #106. Users must curl PUT /api/accounts/:id/service-overrides/{azure|gcp}/{service} to set anything per-account.

What's already wired

• commitmentConfigs.azure._default and commitmentConfigs.gcp._default exist in commitmentOptions.ts with the right terms/payments per provider (Azure: 1yr/3yr × upfront/monthly; GCP: 1yr/3yr × monthly).
• SERVICE_FIELDS in settings.ts:28 already lists Azure (vm/sql/cosmosdb/redis/search) and GCP (compute/sql/memorystore/storage) services.
• The override modal's HTML in index.html is provider-agnostic structurally; only the payment dropdown's static AWS values would need replacing with provider-driven options.
• Backend PUT /api/accounts/:id/service-overrides/:provider/:service accepts any provider — the regex at internal/api/validation.go:36 doesn't care.

Fix direction

Drop the canCreate = provider === 'aws' gate in loadOverridesPanel. Make the modal provider-aware:

• Replace AWS_OVERRIDE_SERVICES const with a per-provider lookup that derives the service list from SERVICE_FIELDS filtered by the account's provider.
• On modal open, populate the payment select dynamically from the provider's commitmentConfigs (or hide it entirely for GCP, which has no payment concept beyond monthly).
• The existing excludes-already-overridden-services logic already filters by o.provider === provider — works as-is.
• The "Inherit" empty option is still meaningful per provider.
• Tests in settings-accounts.test.ts extend the existing Create-override modal describe block with Azure + GCP cases mirroring the AWS ones.

Acceptance criteria

• Settings → Accounts → expand an Azure account's overrides → empty-state auto-opens the modal with Azure-specific service + payment options.
• Same for GCP, with GCP's monthly-only constraint reflected (or payment field hidden).
• Create + reload + the row shows up in the panel.
• AWS behavior unchanged — all of feat(settings): create-override modal for AWS account overrides (closes #104) #106's tests still pass without modification.

Out of scope

• Editing existing rows beyond the inline payment selector — that's tracked separately (Azure/GCP would naturally inherit whichever pattern the AWS edit-row work settles on).
• Backend per-provider validation rules — commitmentOpts.Validate already routes by provider.