Minor version upgrading OPA/Rego compatibility with new language features, (#208)

crypto/JWT support, and build system improvements.

**New Features**
- OPA Rego compatibility upgraded from v1.8.0 to v1.14.1.
- Added template string interpolation support (`$"Hello {name}!"` and
  `` $`raw {expr}` ``), including the `internal.template_string` built-in.
- Added `array.flatten` built-in.
- Added `crypto.*` built-in family: hashing (MD5, SHA1, SHA256), HMAC
  (MD5, SHA1, SHA256, SHA512), X.509 certificate parsing and verification,
  RSA key parsing, and key pair parsing.
  `crypto.x509.parse_and_verify_certificates_with_options` is not yet
  implemented (no OPA conformance tests exist for it).
- Added `io.jwt.*` built-in family: `decode`, `decode_verify`, `encode_sign`,
  `encode_sign_raw`, and signature verification for HS256/384/512,
  RS256/384/512, PS256/384/512, ES256/384/512, and EdDSA.
  EdDSA is only available with the OpenSSL backend.
- Added pluggable crypto backend architecture controlled by the
  `REGOCPP_CRYPTO_BACKEND` CMake option:
  - `mbedtls` (default) — Mbed TLS v3.6.2, built from source via
    FetchContent with zero system dependencies on any platform.
  - `openssl3` — OpenSSL 3.0+ (requires system install).
  - `bcrypt` — Windows CNG (Windows only, no external dependencies).
  - `""` — Crypto disabled; crypto/JWT builtins return an error at runtime.
- Added Windows CMake presets (`debug-windows`, `release-windows`,
  `debug-windows-opa`, `release-windows-opa`) using the `bcrypt` backend.
- Wrapper builds (Python, Rust, .NET) now pass the crypto backend through to
  CMake. Python and .NET use `bcrypt` on Windows and `mbedtls` elsewhere;
  Rust uses `mbedtls` on all platforms.

**Bug Fixes**
- Fixed `numbers.range_step` behavior to match current OPA expectations.
- Fixed `strings.count` with empty substring to return `len(s)+1` instead of
  looping indefinitely, matching OPA semantics.
- Fixed `split` with empty delimiter to split into individual characters,
  matching OPA semantics.
- Fixed JSON object key deduplication to use last-wins semantics, matching
  Go `json.Unmarshal` and OPA behavior.
- Fixed `sprintf` `%v` format to render sets using Rego display syntax
  (`{1, 2, 3}` / `set()`) instead of internal angle-bracket representation.
- Fixed `to_json`/`to_key` rendering of `true`, `false`, and `null` for
  synthetically constructed AST nodes with empty locations.

**Migration Notes**
- JSON objects with duplicate keys now keep only the last value for each key
  ("last-wins" semantics), matching Go `json.Unmarshal` and OPA behavior.
  Previously, duplicate keys were preserved in the AST. If your data documents
  or inputs contain duplicate keys and you relied on earlier values being
  visible, those values will now be silently dropped.
- `crypto.x509.parse_and_verify_certificates` follows OPA's convention: the
  last certificate in the PEM bundle is treated as the leaf (workload)
  certificate; all others are treated as CA or intermediate certificates.
  Revocation checking (CRL/OCSP) is not performed, matching OPA behavior.

**Build & Infrastructure**
- Upgraded Trieste dependency (switched regex engine from RE2 to TRegex).
  Validated against full OPA conformance test suite including regex patterns.
- Removed RE2 from link targets across all build configurations and wrappers.
- CI: Windows PR gate job now uses `release-windows-opa` preset.
- Added test infrastructure for marking tests as `unsupported` (used for
  EdDSA tests on non-OpenSSL backends).

Signed-off-by: Matthew A Johnson <matjoh@microsoft.com>
Signed-off-by: Matthew Johnson <matjoh@microsoft.com>

Author: matajoh

.github/copilot-instructions.md

@@ -0,0 +1,46 @@
+---
+name: bump-version
+description: 'Bump the rego-cpp version number for a new release. Use when: preparing a release, updating version strings after a tag, or when instructed to bump the version. Updates all version files across the main library and wrapper packages to keep them in sync.'
+---
+
+# Bumping the Version
+
+Update all version strings across the rego-cpp project for a new release.
+
+## When to Use
+
+- Preparing a new release (major, minor, or patch)
+- After discovering wrapper versions are out of sync with the main VERSION file
+- When instructed to bump versions
+
+## Files to Update
+
+Every release requires updating version strings in **all** of the following
+locations. Missing any one of them creates a version mismatch between the
+library and its wrapper packages.
+
+| File | Field / Pattern | Example |
+|------|----------------|---------|
+| `VERSION` | Entire file contents | `1.3.0` |
+| `wrappers/python/setup.py` | `VERSION = "X.Y.Z"` | `VERSION = "1.3.0"` |
+| `wrappers/rust/regorust/Cargo.toml` | `version = "X.Y.Z"` | `version = "1.3.0"` |
+| `wrappers/dotnet/Rego/Rego.csproj` | `<Version>X.Y.Z</Version>` | `<Version>1.3.0</Version>` |
+
+## Procedure
+
+1. Read the current version from the `VERSION` file at the repo root.
+2. Determine the new version (from user instruction or by incrementing).
+3. Update all four files listed above.
+4. Verify no other files reference the old version:
+   ```bash
+   grep -rn '"OLD_VERSION"' wrappers/ VERSION
+   ```
+5. Update the CHANGELOG with the new version header if not already present.
+
+## Common Mistakes
+
+- **Forgetting wrapper versions**: The wrapper packages (Python, Rust, .NET)
+  each have their own version string that must match the main `VERSION` file.
+  These are easy to miss because they live in different directories and formats.
+- **Cargo.lock stale**: After updating `Cargo.toml`, run `cargo update` in the
+  Rust wrapper directory if a lockfile exists, or CI may fail.

.github/skills/bump-version/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: code-review
+description: 'Perform a multi-perspective code review of rego-cpp changes. Use when: reviewing a release, auditing a branch diff, evaluating a PR, or performing a pre-merge code review. Launches four parallel review subagents (Security, Performance, Usability, Conservative), verifies key findings, synthesises a unified report with severity-ranked findings, and produces actionable remediation recommendations.'
+---
+
+# Multi-Perspective Code Review
+
+Perform a structured code review by examining changes from four independent
+perspectives, cross-checking findings against source code, and producing a
+unified report with actionable recommendations.
+
+## When to Use
+
+- Before tagging a release
+- Reviewing a large branch diff or PR
+- Auditing a new subsystem (crypto, parsing, VM changes)
+- When a single-perspective review would miss cross-cutting concerns
+
+## Background
+
+A single reviewer tends toward their own bias — a security expert over-flags
+performance patterns, a performance expert under-flags input validation. This
+skill runs four parallel reviews, each with a strict lens, then synthesises
+findings where multiple perspectives converge or provide unique insight.
+
+## Perspectives
+
+| Perspective | Lens | Skill file |
+|-------------|------|------------|
+| **Security** | Defence in depth, memory safety, bounded resources, error handling, adversarial inputs, C API boundaries, fuzz coverage | [plan-security](../plan-security/SKILL.md) |
+| **Performance** | Allocation minimisation, cache-friendly access, pass count, hot-path awareness, algorithmic complexity | [plan-speed](../plan-speed/SKILL.md) |
+| **Usability** | Correctness, clarity, naming, WF precision, error message quality, one-concept-per-pass, API ergonomics | [plan-usability](../plan-usability/SKILL.md) |
+| **Conservative** | Smallest diff, backwards compatibility, API stability, reuse, no speculative generality, blast radius | [plan-conservative](../plan-conservative/SKILL.md) |
+
+## Procedure
+
+### Step 1: Identify the Diff
+
+Determine the commit range or branch diff to review.
+
+```bash
+# Example: changes since last release tag
+git diff --stat v1.2.0..HEAD
+```
+
+Group changed files by subsystem (parser, builtins, VM, C API, build system,
+wrappers) to assign review focus areas.
+
+### Step 2: Launch Four Review Subagents
+
+Spawn four Explore subagents **in parallel**, one per perspective. Each
+subagent receives:
+
+1. The same list of changed files and feature summary
+2. The perspective-specific review lens (from the table above)
+3. Specific files to examine based on the subsystem grouping
+4. Instructions to classify findings by severity and provide file/line references
+
+**Prompt template for each subagent:**
+
+> You are performing a {PERSPECTIVE}-focused code review of rego-cpp.
+> The changes add: {FEATURE_SUMMARY}.
+>
+> Your review lens: **{LENS_DESCRIPTION}**
+>
+> THOROUGHNESS: thorough
+>
+> Please examine these files and report findings:
+> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}
+>
+> For each finding, classify severity as {SEVERITY_SCALE} and provide the
+> file path and approximate line numbers. Return a structured report.
+
+Severity scales per perspective:
+- **Security**: CRITICAL / HIGH / MEDIUM / LOW / INFO
+- **Performance**: HIGH / MEDIUM / LOW impact
+- **Usability**: CONCERN / SUGGESTION / POSITIVE
+- **Conservative**: BREAKING / HIGH-RISK / MEDIUM-RISK / LOW-RISK / OK
+
+### Step 3: Verify Key Findings
+
+After collecting all four reports, identify the highest-severity findings and
+**spot-check them against source code**. Launch a verification subagent:
+
+> For each claim below, read the relevant code and report whether the claim
+> is CONFIRMED, PARTIALLY CONFIRMED, or REFUTED. Provide exact code evidence.
+> {LIST_OF_CLAIMS_TO_VERIFY}
+
+This step prevents false positives from propagating into the final report.
+Mark any unverifiable claims as such.
+
+### Step 4: Synthesise the Report
+
+Produce a unified report with these sections:
+
+#### Convergence
+Where two or more perspectives agree on the same finding. High convergence
+indicates high confidence.
+
+#### Findings by Severity
+A single table combining all verified findings, normalised to a unified
+severity scale:
+
+| Unified Severity | Mapping |
+|-----------------|---------|
+| CRITICAL / HIGH | Security CRITICAL/HIGH, Performance HIGH, Usability CONCERN (correctness bug), Conservative BREAKING |
+| MEDIUM | Security MEDIUM, Performance MEDIUM, Usability CONCERN (non-correctness), Conservative HIGH-RISK |
+| LOW | Security LOW, Performance LOW, Usability SUGGESTION, Conservative MEDIUM-RISK |
+
+Each finding gets: number, description, originating perspective(s), verification
+status, file path and line references.
+
+#### Positive Highlights
+Things the code does well, called out by any perspective. This provides
+balanced feedback and reinforces good patterns.
+
+#### Recommendations
+Ordered by priority. Split into:
+- **Before release**: correctness bugs, UB, security issues
+- **After release**: performance optimisation, tech debt, hardening
+
+#### Trade-offs
+Where perspectives conflict (e.g., security wants more validation, performance
+wants less overhead), state the conflict and the recommended resolution.
+
+### Step 5: Calibrate Against Existing Test Coverage
+
+Before finalising recommendations, check whether existing test suites
+(OPA conformance tests, regocpp.yaml, fuzzer) already cover the flagged
+scenarios. The OPA test suite is comprehensive — findings about "missing
+test coverage" must be verified against:
+
+```bash
+# List OPA test suites
+ls build/opa/v1/test/cases/testdata/v1/
+
+# Check specific suite coverage
+grep 'note:' build/opa/v1/test/cases/testdata/v1/{suite}/*.yaml
+```
+
+Drop or downgrade recommendations that duplicate existing OPA coverage.
+
+## Output Format
+
+The final report should be a structured markdown document (presented in chat,
+not saved to a file unless requested) with the sections described in Step 4.
+
+## Reference
+
+- [Example remediation plan from v1.3.0 review](./references/v1.3.0-remediation-plan.md) —
+  a concrete example of findings and the resulting fix plan.