feat(ladder): require max_hourly_commit_per_run when saving an AWS ladder config #1815

Problem

The ladder sizes the Compute Savings Plan layer from Cost Explorer's account-wide blended rate (cloud-commitments-go#698). That sizing is accepted only because a per-run cap bounds it. The upcoming go pin bump adds a run-time refusal in executeLadderRun: an AWS ladder config with no max_hourly_commit_per_run gets an errored run, with an error naming the field.

Saving still accepts such a config:

• LadderConfigDB.validateLadderRunLimits (internal/config/validation.go) treats a nil cap as "no cap", and it is valid.
• The ladder form (frontend/src/ladder.ts) sends null for a blank cap.

So a user can save a config that every run will then refuse, and only finds out from the run result.

Proposed change

• Validation: an AWS ladder config requires max_hourly_commit_per_run. Mirror the provider-keyed rule in ladderMinLookbackDays and return a 400 that names the field. Update the "nil = no cap (valid)" fixtures in validation_ladder_test.go and the API tests that save uncapped AWS configs.
• Frontend: make the cap required for AWS configs in the ladder form, with an inline error. Update ladder.test.ts and the e2e fixtures that use max_hourly_commit_per_run: null.
• Keep the run-time refusal. Stored rows can already be uncapped, so the save check is an addition, not a replacement.

Acceptance

• Saving an uncapped AWS ladder config returns 400 naming max_hourly_commit_per_run, and the form blocks it.
• Capped AWS configs and non-AWS configs save as before.
• The ladder config page shows why runs stop for an existing uncapped AWS config. For example, it can say "Runs are refused until max_hourly_commit_per_run is set", based on the saved config, or show the errored run's reason if the page shows runs. Owners of rows saved before this check then see the cause without reading the logs.

No data migration or default cap: existing rows stay uncapped until an owner sets a value.