fix(test): settings-purchasing-grace.test.ts has a pre-existing failure on feat/multicloud-web-frontend

[cristim]

Symptom

Multiple PRs in flight (PR #491, PR #454, PR #470, etc.) have flagged the same pre-existing test failure on feat/multicloud-web-frontend:

• File: frontend/src/__tests__/settings-purchasing-grace.test.ts
• The failure reproduces on a clean checkout of origin/feat/multicloud-web-frontend with no local changes (multiple agents confirmed via stash + bisect).

Every CI run on every PR therefore reports a red test, which masks regressions: a real new failure in a PR is harder to notice when the noise floor is 1 failure baseline.

Likely cause

The test was probably valid against an older version of readGraceInput / wireInlineRangeValidation. PR #471 + its #471-follow-up (commit 1c92887be) refactored the grace inputs to flow through wireInlineRangeValidation with requireInteger: true and collapsed the two old error strings into one unified message. The test likely asserts the old error strings.

Fix

Investigate which assertion(s) in settings-purchasing-grace.test.ts are failing. Update them to match the new contract (unified error message Must be a whole number between 0 and 30 + aria-invalid=true on the input + .field-error visible). Or, if the failure surfaces a real regression in the new code, fix that instead.

Severity

P2 — every CI run is red. Affects developer signal-to-noise across all in-flight work.

[cristim]

Verified already fixed by PR #548 (commit on feat/multicloud-web-frontend). The original failing assertion was a stale per-provider error format; PR #478 changed saveGlobalSettings to aggregate failing providers into one toast, and PR #548 brought the test assertion into alignment. PR #795 (just opened) adds an 8-line history comment documenting this chain — that's nice-to-have but not required for this issue's closure.