fix(expr)!: reject regex constructs outside the Python/Rust intersection

[mwiebe]

Fixes: #310

What was the problem/requirement? (What/Why)

Background: OpenJD job template expressions can use regular expressions to
match text — for example re_search('hello123', r'\d+') finds the digits in a
string. The same template might be run by this Rust implementation today and
the Python one tomorrow, so a regex has to mean exactly the same thing
everywhere. The trouble is that Python's regex engine and Rust's regex engine
each have their own special features the other doesn't have. RFC 0006 (and
§2.2.5 of the Expression Language spec) solves this by saying: only the
features that both engines share are allowed — the intersection. Anything
outside it must be an error, so a template author finds out immediately instead
of getting a pattern that silently behaves differently on another
implementation.

Issue #310 reported four Rust-only constructs that slipped through:

• \p{Nd} — Unicode property classes (Python rejects these outright)
• (?<name>...) — Rust's named-group spelling (Python requires (?P<name>...))
• [[:alpha:]] — POSIX classes (Python reads this as an ordinary bracket
  expression that matches different characters — no error, just wrong results)
• [a-z--[aeiou]] — Rust's -- set-difference operator (same silent-mismatch
  problem)

The last two are the worst kind of bug: no error anywhere, just a template
that quietly matches different strings depending on which implementation runs it.

Why it slipped through: pattern validation parsed the regex into
regex_syntax's HIR (a normalized internal form). By that point the
distinctions are already erased — (?<n>a) and (?P<n>a) look identical,
and [[:alpha:]] has already been expanded into a plain character class.

What was the solution? (How)

Validation now walks the pattern's AST (the un-normalized parse tree,
via regex_syntax::ast::Visitor), where all of these constructs are still
visible, and rejects them with the existing
Unsupported regex feature: ... error style. The AST is then translated to
HIR for the pre-existing checks, so the pattern is still parsed only once.

Beyond the four reported constructs, this also rejects the rest of Rust's
class-set extension family — && (intersection), ~~ (symmetric
difference), and nested classes like [a[b]] — because they have the
identical silent-mismatch problem in Python and -- is just one member of
that family.

What is the impact of this change?

Patterns using these Rust-only constructs now produce a clear
"Unsupported regex feature" error instead of being accepted, matching the
spec's dialect. Portable patterns are unaffected.

How was this change tested?

• 10 new integration tests asserting the full error output (message,
  expression, caret), per the repo's test quality standard, plus an
  acceptance test that (?P<name>...) still works.
• Full openjd-expr suite: 3,602 tests pass.
• cargo test --workspace passes (two pre-existing Windows cross-user
  failures reproduce identically on main; environmental).
• Full OpenJD conformance suite: 1,116 passed, 0 failed (Windows).
• cargo clippy -D warnings, cargo fmt, and cargo doc all clean.

Was this change documented?

Yes — the regex validation section of specs/expr/function-library.md now
describes the AST-level dialect enforcement and lists the rejected
constructs. New code has doc comments.

Is this a breaking change?

Yes — the commit is marked fix(expr)! with a BREAKING CHANGE footer.
Regex patterns using \p{...}/\P{...}, (?<name>...), POSIX character
classes ([[:alpha:]]), character class set operators (--, &&, ~~),
or nested character classes ([a[b]]) were previously accepted and are now
rejected with an "Unsupported regex feature" error.

To update: rewrite affected patterns using portable equivalents — e.g.
\d or explicit ranges instead of \p{Nd}, (?P<name>...) instead of
(?<name>...), [a-zA-Z] instead of [[:alpha:]], and an explicit
class like [b-df-hj-np-tv-z] instead of [a-z--[aeiou]]. These
rewrites are also what the spec requires for the template to work on
other conformant implementations.

Does this change impact security?

No.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[leongdl]

Reviewed at tip bb4a93f with the full suite green locally (3609 passed, 0 failed) and a mutation harness over the new rejections: 10/10 suppressed-rejection mutants were caught by named tests, including a combined mutant that disabled both the AST rejection and the HIR backstop for \b{start} — the defense-in-depth is pinned end to end. The AST-level approach is the right one, and the visitor held up under adversarial reading: the byte-offset span slicing in the verbose-class scan is char-boundary-safe, the escape-parity scan handles [\\ ] vs [\ ] correctly, and finish() runs post-traversal so uses_verbose can only over-reject, never under-reject.

One line flagged below where the validator and Python still draw different lines — low severity because the failure mode is loud, but it's the same defect class this PR fixes for ./[/] in group names.

Two nits, no action needed: the bare-flag contiguity check over-rejects (?x) (?i)ab (both engines accept it — verbose mode makes the separating space ignorable), which is the safe direction; and there's no test for # inside a verbose-mode class or for scoped (?R:...), though the flag families are otherwise covered.

One genuinely spec-level item, not this PR's to fix: \w/\d/\s set membership differs at the margins (Python's \w matches ² and ½; Rust's does not). The spelling is shared, so no AST check can see it — same family as the documented bare-$ divergence. Worth a line in the spec discussion alongside RFC 0006 §2.2.5 if there isn't one already.