[FFL-2914] Add targeting regex conformance fixture

[btthomas]

Motivation

FFL-2914 needs one shared set of targeting regex examples before Go, Rust, and web-ui add validation. Without a shared contract, those implementations can accept different patterns or return different match results.

This PR adds test data, documentation, and CI validation only. It does not change production behavior. It is PR0 from the branch strategy and follows the implementation plan.

Changes

FFE regex authoring contract

• Add a standalone v2 fixture with 75 targeting regex cases: 30 accepted and 45 rejected. Its current SHA-256 is 4f8ef95faec9faa3c2b0756ac61afe862e35c0646cba5375532a85335f209e8f.
• Record raw and normalized patterns, an input value, and expected compile and unanchored match results.
• Model Go regexp, RE2JS, the Rust rules-based evaluator, and the Rust rkyv evaluator.
• Record separate expectations when those modeled engines differ.
• Add a SHA-256 file so downstream tests can detect fixture drift.
• Add a jq schema validator and regression tests for invalid fixture forms.
• Document the modeled engines, limits of the evidence, and how consumers should update the contract.

SDK evaluation data

• Add a comma-quantifier allocation proving that a{1,3} remains one regex value.
• Add positive and negative allocation cases proving that edge whitespace is part of the stored regex.
• Keep invalid-regex examples out of the shared regex-flag; invalid syntax remains covered by the standalone contract.

Downstream compatibility preview

• Compare each downstream SDK against both the pull-request base and head fixtures.
• Fail the advisory check only when the base passes and the proposed fixture fails.
• Keep existing downstream drift visible in job summaries and uploaded logs without blocking an unrelated fixture change.
• Prepare writable cache directories for the Python test container.
• Install the curl development package required to build the PHP test target.

Decisions

• Keep the authoring contract under regex-conformance/, not evaluation-cases/. Existing consumers read every JSON file in evaluation-cases/ as a complete UFC evaluation case.
• Keep customer-visible SDK evaluation behavior under evaluation-cases/. These cases use ufc-config.json and the normal SDK evaluation schema.
• Record native expectations for the four implementations represented by its schema: Go regexp, RE2JS, the Rust rules-based evaluator, and the Rust rkyv evaluator.
• Require every accepted case to evaluate consistently in shipped Java, JavaScript, and .NET SDK evaluators too. Named groups, POSIX classes, Unicode properties, combined or scoped Unicode flags, and leading-literal-] classes are rejected because at least one shipped SDK cannot evaluate them consistently.
• Java Pattern, JavaScript RegExp, and .NET Regex are not represented by engineExpectations; the focused downstream checks provide the accepted-case evidence for those evaluators.
• Treat results from SDKs that share the Rust evaluator as correlated evidence, not independent regex-engine evidence.
• Keep the FFE authoring decision separate from native compilation. A native engine accepting rejected syntax does not make that syntax part of the contract.
• Go and RE2JS use the normalized pattern. Rust uses the raw pattern.
• Do not add a regex length limit.
• Treat the general downstream matrix and the focused regex matrix in PR 23 as compatibility evidence, not automatic decisions about the contract.

Downstream dd-source changes must wait until this PR is merged into main before pinning the new fixture commit.

Customer remediation before enforcement

The newly rejected syntax is valid in some current evaluators, so existing customer configurations may already use it. Before dd-source enables strict write validation, the release owner must audit active allocations, saved filters, pending suggestions, and published or locked protocol templates for the five newly rejected syntax families.

The audit must report identifiers and counts without regex values. The owning team must review each result with the customer or support owner and edit or delete the affected regex or targeting rule before enforcement. If safe remediation is not complete, backend enforcement must wait or the implementation plan must define an explicit compatibility policy.

Validation

python3 ci/validate-fixtures.py
jq empty ufc-config.json evaluation-cases/*.json regex-conformance/targeting-regex-conformance.json
jq -e -f regex-conformance/validate-targeting-regex-conformance.jq regex-conformance/targeting-regex-conformance.json
regex-conformance/test-validate-targeting-regex-conformance.sh
(cd regex-conformance && shasum -a 256 -c targeting-regex-conformance.sha256)
bash -n ci/run-downstream-conformance.sh
git diff --check

Results:

• Validated 269 SDK evaluation cases across 37 files.
• The regex validator accepts the checked-in fixture and rejects the tested invalid forms.
• All 75 case IDs are unique. There are no duplicate pattern/input pairs or duplicate cases with the same meaning.
• The checked-in SHA-256 matches the fixture bytes.
• PR 23 identified nine previously accepted cases across five syntax families that are not evaluated consistently by shipped Java, JavaScript, or .NET SDK evaluators. This revision reclassifies all nine as rejected.
• The focused downstream matrix must be rerun against this commit. Accepted-case mismatches are contract failures. Rejected cases may differ in native acceptance without requiring an SDK production change because dd-source will block them at authoring boundaries.
• Python, Ruby, PHP, and libdatadog largely exercise the shared Rust evaluator, so their results are correlated.
• The general compatibility matrix can still report existing SDK behavior differences. Those differences remain visible but do not automatically represent regressions introduced by this fixture.

Checklist

• JSON files are valid.
• New evaluation cases reference the existing regex-flag in ufc-config.json.
• The updated regex flag configuration has matching evaluation coverage.
• Expected results match the flag configuration logic.

[leoromanovsky]

📈 📈 📈