fix: correct CRS 3 variable names and examples for CRS 4

[fzipi]

what

corrects five places where the documentation contradicts crs-setup.conf.example or the current rule set, all of them CRS 3 residue:

• 2-2-paranoia_levels.md — tx.paranoia_level -> tx.blocking_paranoia_level, in both the native-install and the vendor-integration paragraph
• 2-2-paranoia_levels.md — the executing paranoia level is the detection paranoia level in CRS 4; renamed in the heading, body, example caption and image alt text, and the variable (tx.detection_paranoia_level, rule 900001) is now named so the section is actionable
• 2-1-anomaly_scoring/index.md — the 920160 example set tx.anomaly_score_pl1; the variable is tx.inbound_anomaly_score_pl1. ver: in the same block said 3.4.0-dev, updated to the release the site already references. The cross-reference to the paranoia level feature follows the rename
• 2-3-false-positives-and-tuning.md — rule exclusion packages became plugins in CRS 4. tx.crs_exclusions_* no longer exists anywhere in rules/, and rule 900130 now initializes default collections, so the instructions and the three tip snippets were no-ops. Replaced with a pointer to the plugins page, which already documents the current WebAppID/Host scoping pattern
• 6-4-using-the-crs-sandbox.md — sample output showed rule 980130; RESPONSE-980-CORRELATION.conf only defines 980170, and the message format changed

why

each of these silently misleads. Setting tx.paranoia_level in crs-setup.conf does nothing at all in CRS 4 — there is no back-compatible alias — so a reader following that paragraph stays at the default paranoia level believing they raised it. The exclusion-package instructions point at a rule ID that now controls an unrelated feature. 1-1-crs-installation.md already states that exclusion packages were replaced by plugins, so the two pages disagreed with each other.

the sandbox blocks were regenerated from live requests to sandbox.coreruleset.org rather than hand-edited. The posix_uname() example no longer matches any rule, so that example uses system() (933160) instead, with its real response.

refs

• crs-setup.conf.example rules 900000, 900001, 900130
• rules/RESPONSE-980-CORRELATION.conf
• chore: remove util/php-dictionary-gen coreruleset#4711 for the plugin migration context

not changed here, but noticed while checking:

• 6-4-using-the-crs-sandbox.md "Default options" says the default CRS version is the latest release; the sandbox currently answers with x-backend: apache-v4-lts, and the backend table still lists apache-latest / apache-3_3_8 as available values
• 13 of the 26 settings in crs-setup.conf.example are not documented anywhere, tx.detection_paranoia_level among them — worth a reference page, but that is a bigger piece of work than this PR

ai disclosure

• tools used: Claude (Opus 5), via Claude Code
• assisted with: diffing every crs-setup.conf.example setting against the docs, the edits, and this description
• review performed: confirmed against the rule set that tx.paranoia_level and tx.crs_exclusions_* exist nowhere in rules/ or crs-setup.conf.example, that 900130 now sets tx.enable_default_collections, and that 920160 sets tx.inbound_anomaly_score_pl1; captured every sandbox sample from live requests, including the discovery that posix_uname() no longer matches; ran hugo --minify, english_test.sh and lychee over the changed files, and verified in the built HTML that both new ref links resolve and the #conditionally-enable-plugins-for-multi-application-environments anchor exists

[cloudflare-workers-and-pages]

Deploying crs-documentation with    Cloudflare Pages

Latest commit:	9a67d68
Status:	✅  Deploy successful!
Preview URL:	https://ac54dba1.documentation-km5.pages.dev
Branch Preview URL:	https://docs-crs4-terminology-fixes.documentation-km5.pages.dev

View logs

[M4tteoP]

lgtm