ci: add a debug Rust test gate

[membphis]

Background

qjson is performance-sensitive, so the main Rust CI path intentionally tests release builds:

• cargo build --release
• cargo test --release
• cargo test --release --no-default-features
• cargo test --features test-panic --release

That matches the artifact shape users care about, but it leaves one small CI blind spot: normal Rust debug tests are not part of the pull request gate.

Debug builds provide useful additional signals that release builds may miss, especially around integer overflow checks, debug assertions, and local developer parity. Developers and AI coding agents commonly run cargo test or cargo test --no-default-features locally while iterating, so CI should have at least one lightweight debug-mode Rust test check.

Goal

Add a small debug-mode Rust CI gate so pull requests exercise at least one non-release Rust test configuration.

Proposed Scope

Add one focused CI step/job that runs a debug Rust test command, preferably one of:

cargo test --no-default-features

or, if the implementation decides the default-feature path is more useful:

cargo test

The preferred first choice is cargo test --no-default-features because it exercises the scalar scanner in debug mode and avoids making the debug gate depend on SIMD feature availability or release-like performance.

This gate should be additive to the existing release test matrix. It should not replace any release, scalar-only release, panic-barrier, fuzz, Miri, ASan, Lua, or package checks.

Non-Goals

• Do not run Lua busted tests against a debug Rust cdylib in this issue.
• Do not add a new Makefile target; local Rust debug testing already has direct cargo test commands.
• Do not change the existing make test behavior.
• Do not change the existing release test matrix.
• Do not introduce Rust formatting policy changes or cargo fmt --check.
• Do not broaden this into sanitizer, Miri, Valgrind, or fuzz changes.

Acceptance Criteria

• Pull request CI includes a Rust debug-mode test gate.
• The gate runs at least one non-release cargo test command.
• The gate is small and focused, with no unrelated workflow restructuring.
• Existing release-mode Rust tests continue to run.
• Existing Lua, fuzz, sanitizer, audit, package, and release validation workflows are not weakened.
• The selected command is documented clearly in the workflow step name, for example Test debug scalar-only or Test debug.

Implementation Notes

A minimal implementation can add a step to the existing Rust CI job after the stable toolchain is installed. If runtime cost becomes noticeable, keep the debug gate scalar-only with --no-default-features.

If the debug test exposes a real issue, fix the issue in the same PR only if the fix is narrow. Otherwise, record the failure details and split the functional fix into a separate issue/PR.

[coderabbitai]

🔗 Related PRs

#43 - test: add cjson and simdjson fixture coverage [merged]
#51 - perf: skip redundant validation in eager decode, inline depth check [merged]
#78 - test(fuzz): add nesting-depth stack-safety target [merged]
#85 - chore: add cargo-audit CI gate and CHANGELOG skeleton [merged]
#92 - docs: add no-Rust runtime deployment guide [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!