Policy profiles: seed a policy with app-specific CRS exclusions (WordPress, Nextcloud, …)

[bihius]

Summary

Add the ability to create a policy seeded with application-specific default rule
exclusions (e.g. WordPress, Nextcloud) so an admin can stand up a sane, low-FP
policy for a common app without hand-tuning CRS.

OWASP CRS 4.x already ships official exclusion packages for: cPanel, DokuWiki,
Drupal, Nextcloud, phpBB, phpMyAdmin, WordPress, XenForo. This feature packages
those existing exclusions as selectable "profiles" — it does not invent new rules.

See notes/decisions/crs-open-questions.md
§1, §2, §5 for prior thinking.

Motivation

• CRS + a real app (especially WordPress) produces many false positives out of the box.
• Tuning is normally weeks of work on production traffic; an app profile gives a
  reasonable starting point in one click.
• Demonstrates the project's management value: the before/after FP delta of applying
  a profile is exactly the kind of tuning-workflow evidence the thesis evaluation wants
  (reported as a relative delta, not an absolute SLO — see README.testing.md).

Scope

• Profile catalogue backed by the CRS exclusion packages already in the submodule
  (generic = no app exclusions, plus wordpress, nextcloud, … as available)
• "Create policy from profile" path in the backend (policy seeded with the profile's
  exclusion set + base CRS config)
• Profile selector in the policy-create UI
• Config generator emits the corresponding CRS exclusion plugin includes
• Docs: how profiles map to CRS exclusion packages; note this is a starting point,
  still requires tuning

Out of scope

• Authoring new exclusion packages for apps CRS doesn't cover (Joomla, Moodle,
  Gitea, …) — separate future-work item (crs-open-questions §5).
• Questionnaire-driven / LLM-assisted exclusion suggestion (crs-open-questions §2) —
  separate item.

Notes

• Verify which CRS version the pinned submodule bundles; the exclusion plugins moved to
  a separate coreruleset/plugins repo in CRS 4 — wiring may need that plugin set.
• Per-variable vs per-rule granularity is tracked separately (crs-open-questions §3);
  profiles use whatever granularity the upstream CRS package ships.

Post-MVP — not required for the thesis MVP. The MVP already supports manual
per-rule overrides; this is a convenience layer on top.