Make safety audits understand safe helper and negative-policy semantics

[Widthdom]

Summary

The static-regex audit treats Regex.Escape as risky regex construction, and the shell-execution audit reports the central UseShellExecute=false no-shell policy as its only hit.

Audit IDs: R-15 and R-16. Reproduced with locally built cdidx v1.40.3 at 404db09489c305f17d94f37026e00564d3ac527a.

Existing issue relationship

Follow-up adjacent to closed #3920 and #4131's built-in safety recipe work.

Expected behavior and PR scope

Recipes should reason about operation/polarity: escaping is not execution/compilation, and explicit disabling of shell execution is not risky enablement. One semantic-safe-API/policy PR.

Implementation guide for Codex 5.6 sol xhigh

• Model matched API/member and assigned/argument value rather than relying on nearby words.
• Add safe negative controls (Escape, false) and unsafe positives (new Regex, matching/execution, UseShellExecute=true or shell launch).
• Keep alias/qualification/object-initializer/variable-propagation cases conservative and explain evidence.
• Do not add file/path/name allowlists.
• Add focused positive/negative regression tests, run the full net8.0 and net9.0 suite, and add the required bilingual changelog.d/unreleased/ fragment.

Acceptance criteria

• The two safe current sites are not findings.
• Unsafe positive controls remain findings with useful evidence.
• Recipe metadata documents the semantic distinction.