Normalize 'savings-plans' vs 'savingsplans' identifier across frontend + backend

[cristim]

Problem

Savings Plans is identified inconsistently across the stack:

Layer	File	Identifier
Frontend dropdown	frontend/src/index.html:112,703	"savingsplans"
Frontend SERVICE_FIELDS	frontend/src/settings.ts:32	"savingsplans"
Frontend commitmentConfigs	frontend/src/commitmentOptions.ts:58	"savingsplans" (after #63)
Backend canonical	pkg/common/types.go:49	"savings-plans"
Backend CLI flag	cmd/main.go:92	"savingsplans"
Backend purchase normaliser	internal/purchase/execution.go:384	accepts both via case "savings-plans", "savingsplans":

The frontend persists "savingsplans" to the service_configs.service column. The Go ServiceType constant is "savings-plans". The two sides only line up because execution.go does a dual-case branch on the way to common.ServiceSavingsPlans. Other services don't have the same compatibility shim, so it's load-bearing for Savings Plans alone.

Why it matters

• Any new code path that compares ServiceConfig.service against common.ServiceSavingsPlans directly (without the normaliser) will silently miss Savings Plans rows.
• Adding a third identifier form (e.g., "savings_plans") anywhere is now extra-cheap and an easy oversight.
• The execution.go case "savings-plans", "savingsplans": branch suggests historical drift — pinning a single canonical removes the foot-gun.

Out of scope (handled in #63)

#63 addressed a downstream consequence — the frontend commitmentOptions.ts had registered the AWS Savings Plans config under "savings-plans" while every other frontend call site used "savingsplans", causing all lookups to fall through to _default. That's now fixed within the frontend's own naming scheme; this issue tracks the broader frontend↔backend split.

Suggested approach

Pick one canonical and migrate the other side, with care for persisted rows:

• Option A — converge on "savings-plans" (backend canonical): requires a one-shot SQL migration to rename service_configs.service rows from "savingsplans" → "savings-plans", plus updating the dropdown option values, SERVICE_FIELDS, and commitmentConfigs. Aligns with the pkg/common/types.go constant.
• Option B — converge on "savingsplans" (frontend canonical): change pkg/common/types.go:49 to "savingsplans" (Go-side enum-style change is safer than a DB migration), drop the case "savings-plans" branch from execution.go:384, audit Go callers for hardcoded "savings-plans" strings.

Either option ends with a single normaliser at the API boundary and removes the dual-case branch.

Acceptance

• One canonical service identifier for Savings Plans across frontend + backend + DB.
• The dual-case branch in execution.go:384 removed.
• A regression test that fails if a future commit reintroduces a divergent identifier.

Discovered while sweeping CodeRabbit nitpicks in #63.

[cristim]

Audit during batch implementation — current state of the four acceptance pieces:

1. "One canonical service identifier" — partially achieved. pkg/common/types.go:54 already pins canonical to "savings-plans" (hyphenated) and the per-plan-type slugs from feat(settings): per-plan-type Savings Plans configuration (closes #22) #123 (savings-plans-compute/etc.) all follow the hyphenated form. Frontend has largely moved off the bare savingsplans slug except for a couple of legacy spots:

   • frontend/src/commitmentOptions.ts:58 — savingsplans: key in commitmentConfigs map (lookup key, not service ID).
   • Comments/test names in settings.ts:68-69, 484, commitmentOptions.test.ts:39, 186-188 referencing the umbrella form.

2. Drop the dual-case branch in execution.go — blocked by chore(purchase): drop legacy "savings-plans" mapServiceType alias once historical rows age out (follow-up to #85) #95, which explicitly waits for historical rows persisted under the savingsplans form to age out. Removing the branch now would 404 any PUT /api/config/service/savingsplans from a script that hasn't switched to per-plan-type slugs yet.

3. cmd/main.go CLI dual-form — still accepts both savingsplans and savings-plans (and sp). Same constraint as (2): scripted setups out in the wild.

4. Regression test guarding against a third identifier — not yet present. Achievable as an isolated commit; the rest of the work depends on chore(purchase): drop legacy "savings-plans" mapServiceType alias once historical rows age out (follow-up to #85) #95 finishing first.

Recommendation: keep this issue open as the umbrella for the eventual full normalization. When #95 lands (historical rows aged out), this issue's remaining work shrinks to just removing the dual-case branches and that one commitmentOptions.ts map key. The lone regression test would catch a future fourth-form drift.

Skipping for batch implementation — would either be too small (just the regression test) or too risky (touching the dual-case alias before #95 is ready). Worth picking up after #95 closes.

[cristim]

P3 cleanup, blocked on #95 (historical "savings-plans" rows aging out ~6 months post-PR #94 merge). Comment from @cristim (2026-04-28) confirms the dual-case branch in execution.go:384 cannot be removed yet — leave open as an umbrella until #95 closes. (triage agent wave1-A)