fix: accept {n,} patterns and localize setup-field hints

[Weegy]

Two defects in the setup-field validation shipped in #599. Both were found by writing the first real plugin manifest against it (byte5ai/omadia-google-workspace#1), and neither was visible from inside this repo. Closes items 6 and 7 of #605.

1 · The allowlist refused {n,} while allowing +

screenPatternSource rejected open-ended counted repetition with "open-ended counted repetition {n,} is not allowed" — while +, which is exactly {1,}, passed. Equivalent constructs, opposite verdicts: no safety bought, only author cost.

Not hypothetical. The first realistic pattern written against this feature, ^[^@\s]+@[^@\s]+\.[A-Za-z]{2,}$ for an email TLD, was refused and had to be respelled as [A-Za-z][A-Za-z]+. The agent who wrote the allowlist flagged the inconsistency at the time and complied with the spec anyway.

Shape is now judged purely by the group-content rules that already govern + and *, which fire on every quantifier spelling. Size checking stays separate.

A guard had to be added, not just removed. {n,}'s only number is the minimum, which nothing needed to bound while the construct was illegal. MAX_COUNTED_REPETITION now applies to max(min, max) — without it, a{100000,} would have become legal the instant the shape check stopped rejecting it.

Every hostile pattern is still rejected, and now also in its counted spelling — ^(a|a){1,}$, ^(a{1,})+$, ^((a{2,})){2,}$, ^(?:a|a){2,}$, ^(?=a{1,})b$ — so the {n,} form cannot open a door the + form keeps shut.

Measured, rather than assumed, on node 22:

pattern	subject	time
^[a-z]{1,100000}[a-z]{1,100000}$	8191 non-matching chars	71 ms
^[a-z]+[a-z]+$ (always been allowed)	same	39 ms
^a{100000,}$ compile + match	100k chars	0.43 ms

A huge {n,m} is the same polynomial class as the + this allowlist has always accepted — ~2×, not a new cliff — and V8 uses a counter rather than unrolling, so there is no compile-time blowup either. The cap is defence-in-depth; the 50 ms worker budget is the actual floor. The threshold stays at 100 because it covers every shape this feature exists for (DNS label ≤63, TLD 2–63, SHA-256 hex 64); raising it deserves its own evidence.

Known conservatism worth a follow-up: [0-9a-f]{128} — a 512-bit hex key, a plausible credential — is still refused at 100. Visibly, via pattern_unavailable, not silently.

The client had the same bug, and there it was worse

web-ui/app/_lib/setupFieldPattern.ts carries a hand-mirrored copy of the grammar including the identical {n,} rejection. Fixing only the server would have made a {2,} pattern unusable client-side: no native pattern= attribute, and violatesSetupPattern fails open. The operator types a bad value, sees nothing, hits Save, and eats a 400 from a check the client had silently opted out of. Both halves are fixed together.

2 · The server always returned the English hint

checkSetupFieldPattern picked the hint via pickPatternHint(field.pattern_hint, locale), but runtime.ts called it with three positional arguments and never passed a locale — so every 400 runtime.setup_field_invalid carried English regardless of UI language. installService had the same gap.

Bounded impact — CredentialsEditor localizes correctly and blocks save before submitting, so the 400 is the fallback path (install wizard, API clients, any route bypassing the client check). But "English field labels and help texts in a German UI" is one of the named contributing factors of OM-17 itself, so shipping the fix with an English-only server message is a small own goal.

Fix: the client resolves the hint from the field it already holds, keyed on the violation's field, with the server's hint as fallback when the field is unknown. New resolveSetupFieldHint(); used by the post-install editor and the install wizard alike.

No API change. hint stays the documented English fallback for clients that have no manifest (curl, install CLI, integrations), so an older client renders exactly what it renders today.

Why not thread the locale server-side

Investigated and rejected: middleware has zero locale plumbing — no Accept-Language read anywhere in middleware/src, and LOCALE_COOKIE/NEXT_LOCALE never leaves the Next.js layer. That option means building locale plumbing so the server can pick a language for a client it cannot see — the same "untranslatable string smuggled in through the API" mistake setupFieldPattern.ts warns against, in a different costume. The unused locale parameter was removed rather than left implying a threading that does not exist.

One small type change followed: FieldRow's error prop went from string to { code?, message }, because for a pattern_mismatch the server's message is the English hint and the component cannot otherwise tell it apart. Only pattern_mismatch is overridden; required / wrong_type render verbatim. No new i18n keys — the text is manifest content.

Verification

Mutation-tested, all five red before green:

mutation	result
restore the {n,} rejection (middleware)	8 fail — incl. {2,}, {100,}, the end-to-end match, the realistic-manifest test
drop the new min cap only	2 fail — ^a{101,}$, ^a{100000,}$
restore the {n,} rejection (client mirror)	6 fail
resolveSetupFieldHint → return the server hint	3 fail — German-preferred, English-operator, cross-locale fallback
FieldRow → always render error.message	2 fail — German error in wizard and in editor

Loaded the real Google Workspace manifest through loadManifestFromPath (read-only, throwaway script — no test depends on that path): all four fields pattern_unavailable=false, refused-pattern registry empty. Re-ran it with the workaround rewritten back to the {2,} the author actually wanted: still all four intact, registry still empty — so that plugin PR can drop its workaround once this lands.

middleware   typecheck clean · 5495 pass / 0 fail / 4 skipped   (was 5471)
web-ui       typecheck clean · lint 0 errors (38 pre-existing warnings)
             i18n:check OK — 3339 keys, en + de (unchanged)
             vitest 68 files / 552 tests pass                    (was 526)

One unrelated thing found, not fixed here

Driving setupFieldPattern.ts standalone under node --import tsx --input-type=module -e, every matchWithBudget call overruns the 50 ms budget — even /^a$/ against 'a', at 84–212 ms. Once one overruns the worker is terminated, so the next call pays boot cost again and overruns too: a self-sustaining loop that fails every value closed. Reproduces identically with this branch's changes stashed, so it is on main, and the node --test harness does not hit it. Likely worker boot under tsx's loader exceeding the budget. Out of scope, but it would bite anything driving this module outside the test runner.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}