Add inline validation for preset fields with regex pattern

[Shyam-123pandey]

Add inline validation for fields that define a regex pattern

Summary

This PR adds inline validation support for preset fields that define a pattern (regex).

If a field includes a regex pattern and the entered value does not match it, an informational message is displayed directly below the input field.

Behavior

• Validation runs on blur / change, not while typing.
• The message appears only after the user finishes editing the field.
• If the value becomes valid, the message disappears.
• This does not block saving.
• This does not create or modify issues in the issues panel.
• It only applies to fields that define a pattern.

Why

Some fields may define a regex pattern but currently provide no direct feedback when the value does not match the expected format.

This change improves UX by giving contextual, field-level feedback after editing is complete, while staying consistent with iD’s existing interaction model (no validation on every keystroke).

Scope

• Changes limited to uiFieldText.
• No changes to the validation engine.
• No preset/schema changes.

Closes #10769

[Copilot]

Pull request overview

Adds inline, non-blocking validation feedback for text inputs whose preset field definition includes a regex pattern, improving UX by showing/hiding a message as the user types.

Changes:

• Add a validation message element to uiFieldText’s DOM structure.
• Validate input values against field.pattern during change() and toggle the message visibility/text accordingly.

[Copilot]

new RegExp(field.pattern) is created on every input event. Since field.pattern is stable per field, consider compiling/caching the RegExp once (and reusing it) to avoid repeated allocations while typing. If you do cache it, make sure to reset lastIndex before testing in case a global/sticky flag is ever present.

Suggested change

	let regex = null;
	try {
	regex = new RegExp(field.pattern);
	} catch (e) {
	regex = null;
	// Compile and cache the RegExp once per field to avoid repeated allocations
	// and reuse it on each input event. Recompile only if the pattern changes.
	if (!field._compiledPattern || field._compiledPatternSource !== field.pattern) {
	try {
	field._compiledPattern = new RegExp(field.pattern);
	field._compiledPatternSource = field.pattern;
	} catch (e) {
	field._compiledPattern = null;
	field._compiledPatternSource = field.pattern;
	}
	}
	const regex = field._compiledPattern;
	if (regex) {
	// Ensure consistent behavior if global or sticky flags are ever used
	regex.lastIndex = 0;

[Shyam-123pandey]

I will change this to suggested change and then testing.

[Shyam-123pandey]

Copilot suggested caching the compiled RegExp on the field object to avoid re-creating it on each input event.
Since field.pattern is stable, this could reduce allocations while typing. However, this would introduce additional state (_compiledPattern) on the field object.
Would you prefer:

• Keeping the simpler approach (compile per input, minimal logic), or
• Caching the RegExp for slight optimization?

I’m happy to adjust based on project conventions.

[Shyam-123pandey]

Please suggest me about above changes so that i can move furthur.

[matkoniecz]

1. have you wrote this code yourself or got it generated by LLM?

2. have you looked are there other warning like this supported existing code?

[Shyam-123pandey]

Good After noon Sir, Almost things have been resolved just check , I have doubt on one issue as copilot suggested please check above, so suggest for that.

[matkoniecz]

if this field has no patter, it should not be hardcoded here but defined with other patterns