docs: note ModSecurity v3/nginx incompatibility, skip nginx in CI

[fzipi]

Summary

• Documents in the README that this plugin does not currently work with ModSecurity v3 (nginx connector): plugins/body-decompress-before.conf ends its chain with a bare SecRuleScript (no action list), which is valid under ModSecurity v2 (Apache) but fails to parse under ModSecurity v3, breaking every following directive. Tracked upstream at SecRuleScript actions always considered disruptive owasp-modsecurity/ModSecurity#3108 (still open).
• Restricts the integration-tests workflow to apache only (backends: '["apache"]'), since the nginx matrix jobs currently fail because of this upstream parser bug rather than anything under our control.

Test plan

• actionlint .github/workflows/integration.yml passes
• yamllint .github/workflows/integration.yml shows no new issues (pre-existing line-length warning on line 7 confirmed present before this change)
• Confirm CI now runs green with only the apache backend

🤖 Generated with Claude Code

[fzipi]

Update on the remaining CI failure here: once nginx was excluded, the Apache job started running to completion and surfaced a separate, pre-existing bug — the plugin's own regression test 9503110-1 fails against both CRS main and the v4.25.1 LTS.

Root cause: CRS v4.4.0+ added an unconditional "skip if compressed" guard to the top of every RESPONSE-95x rule file (e.g. rule 953010 in RESPONSE-953-DATA-LEAKAGES-PHP.conf), keyed only on the Content-Encoding response header. Since this plugin never touches that header, the guard skips past the retargeted rules (SecRuleUpdateTargetById ... TX:RESPONSE_BODY_DECOMPRESSED) before they ever run — so the plugin's decompressed body is never actually scanned under current CRS v4. It worked fine through CRS v4.3.0; the guard was introduced in coreruleset/coreruleset#3742.

Filed upstream: #18

This is unrelated to the CI/docs changes in this PR and will need a CRS-side fix (or an agreed workaround here) before the Apache integration job can pass again.