ux(settings): inline edit Term/Coverage + Enabled toggle on existing override rows (V2 of #72)

[cristim]

Summary

PR #72 made the Payment column on existing override rows editable via an inline <select>. The other three editable fields on account_service_overrides — term, coverage, enabled — remain read-only. To change any of them today, users must hit Reset (which deletes the row entirely, losing all field values) and recreate the override from scratch via #106's modal.

Two concrete user-visible gaps:

1. No way to change Term or Coverage on an existing row without losing the other settings.
2. No way to pause an override without deleting it. The account_service_overrides.enabled column exists (internal/database/postgres/migrations/000011_cloud_accounts.up.sql:78), the backend's applyOverrideScalars honours it, but no UI exposes the toggle.

What's already wired

• Inline-cell editing pattern: buildPaymentOverrideSelect in frontend/src/settings.ts (added by ux(settings): add payment option selector to AWS account overrides modal #72) is the template. It writes a sparse PUT (just { payment: ... }) so other fields are preserved by applyOverrideScalars. The same shape extends naturally to term/coverage/enabled.
• Backend supports partial updates today — every field on account_service_overrides is nullable, and saveAccountServiceOverride (internal/api/handler_accounts.go:818) merges request fields onto the existing row.
• commitmentOptions.ts already has getValidTermOptions(provider, service, payment) so a Term inline-select can constrain options per the row's current payment, mirroring ux(settings): account override UIs should reuse commitmentOptions validity rules (e.g., RDS 3yr no-upfront) #107's plan.

Fix direction

Three small extensions to loadOverridesPanel's row rendering, each independently shippable:

• Term cell: replace the static ${o.term}yr text with a <select> (1yr / 3yr / Inherit) constrained by getValidTermOptions('aws', o.service, o.payment ?? ''). Change handler PUTs { term: n } only.
• Coverage cell: replace the static ${o.coverage}% text with a numeric input (0–100, step 1) with debounced save. Change handler PUTs { coverage: n } only. Validate before sending (out-of-range → revert + toast).
• Enabled toggle: a per-row checkbox. PUT { enabled: bool } on change. When false, dim the row visually so it's clear the override exists but isn't influencing recommendations.

Each follows #72's "sparse PUT preserves other fields" + "current value rendered, server roundtrip on change" + "revert + toast on error" pattern verbatim.

Acceptance criteria

• Term, Coverage, and Enabled are editable in-place on existing AWS override rows. Each change persists via a sparse PUT and survives a reload.
• The Reset button is preserved (still the only path to fully delete a row).
• Validity rules from ux(settings): account override UIs should reuse commitmentOptions validity rules (e.g., RDS 3yr no-upfront) #107 (e.g., RDS 3yr no-upfront) apply to the Term cell's options the same way ux(settings): account override UIs should reuse commitmentOptions validity rules (e.g., RDS 3yr no-upfront) #107 wires them for the Payment cell.
• Disabled rows render with a dimmed visual treatment.
• Tests in settings-accounts.test.ts cover each new cell's render-current-value + change-sends-sparse-PUT + invalid-input-reverts paths.

Out of scope

• Editing provider/service on an existing row — the row's identity is (account_id, provider, service), so changing those is delete-then-create. Reset + feat(settings): create-override modal for AWS account overrides (closes #104) #106's modal already covers it.
• The include_engines/exclude_engines/include_regions/exclude_regions/include_types/exclude_types array fields. Filing as their own issue (or leaving API-only) once user demand surfaces.
• Azure/GCP — depends on the provider-aware modal work tracked separately.