fix(spec): specify ECMA-262 dialect for regex Criterion condition type

[char0n]

Closes #515

Summary

The Criterion Object's regex condition type did not name a regular-expression dialect, while the sibling jsonpath (RFC 9535) and xpath (XML Path Language 3.1) types both pin a standard. This left regex matching non-portable across Arazzo runners: dialects differ in lookbehind (?<=…), named groups, backreferences, and Unicode property escapes \p{…}, so a condition such as (?<=x)y or \p{L}+ could pass on one runtime and fail (or error) on another.

This PR pins ECMA-262 for the regex type, matching OpenAPI / JSON Schema Validation (the sibling specification under the OAI, which pins ECMA-262 for pattern/patternProperties) and what the most common runners implement via native regex engines.

Changes

Two clarifying edits to src/arazzo.md, both linking to the ECMA-262 patterns grammar:

• Criterion Object condition flavors list — the regex entry now states the pattern MUST be a valid regular expression according to the ECMA-262 dialect.
• Regex Conditions evaluation section — the condition MUST be a valid ECMA-262 regular expression.

This is a clarification that does not change the intended meaning of the specification, so it targets v1.1-dev per the branching strategy (apply to the earliest relevant active branch). markdownlint passes.

[handrews]

Please note that as of this week, in the JSON Schema IETF working group we are considering settling on I-REGEXP as a more feasible common ground. ECMA262 support, while technically recommended (SHOULD) by JSON Schema, is not, in pracitce, widely correctly supported.