[FR] Support EU DORA & NIST CSF 2.0 Compliance Tags and FAIR Financial Risk Metadata in Rule Schemas

### Repository Feature
Core Repo - (rule management, validation, testing, lib, cicd, etc.)

### Problem Description
Currently, detection rules in `elastic/detection-rules` support MITRE ATT&CK (`[[rule.threat]]`), severity levels, and tags (e.g. `OS: Windows`, `Tactic: Collection`).

However, enterprise financial institutions and critical infrastructure organizations subject to the newly enacted **EU Digital Operational Resilience Act (EU DORA - Regulation (EU) 2022/2554)** and **NIST Cybersecurity Framework (CSF) 2.0** require detection rules to be mapped directly to compliance controls (e.g., Article 9.2 for credential & access abuse, Article 10 for continuous ICT monitoring, and NIST CSF 2.0 PR.AC/DE.CM).

Furthermore, modern SOC leadership and CISOs require translating technical risk scores (0–100) into **FAIR (Factor Analysis of Information Risk) Cyber Risk Quantification (CRQ)** attributes (Single Loss Expectancy, Asset Criticality Tiers) so that detection coverage correlates directly with capital at risk.

Without standardized compliance tags and financial impact metadata:
1. Detection engineers must manually maintain bespoke out-of-band spreadsheets to prove DORA and NIST CSF 2.0 detection coverage.
2. Security Operations cannot filter or prioritize alerts based on regulatory scope or asset criticality.

### Desired Solution
1. **Extend Rule Tags Schema**:
Support standardized tags for modern compliance frameworks:
- `Compliance: EU DORA`
- `Compliance: NIST CSF 2.0`
- `Compliance: SOC 2 Type II`

2. **Compliance Control References**:
Allow detection rules to reference regulatory articles in their metadata or tags:
- `DORA: Article 9.2 (Access Control & Identity)`
- `DORA: Article 10 (Continuous Monitoring)`
- `NIST CSF 2.0: PR.AC-01`
- `NIST CSF 2.0: DE.CM-01`

3. **Financial Risk & Criticality Alignment**:
Provide guidance or custom metadata fields linking `risk_score` to asset criticality tiers (Tier 0 to Tier 3) and FAIR economic impact metrics.

Example rule header:
```toml
tags = [
"Domain: Endpoint",
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Compliance: EU DORA",
"Compliance: NIST CSF 2.0",
"DORA: Article 9.2",
"NIST CSF 2.0: PR.AC-01",
]
risk_score = 73
severity = "high"
```

### Considered Alternatives
- Relying exclusively on manual post-ingestion tagging in Logstash or ingest pipelines, which breaks rule-as-code synchronization and increases maintenance debt across multi-cluster deployments.

### Additional Context
- EU DORA: [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554)
- NIST CSF 2.0: [NIST CSWP 29](https://doi.org/10.6028/NIST.CSWP.29)
- Reference architecture and implementation: [AAH20/wazuh-elastic-sovereign-vciso-control-plane](https://github.com/AAH20/wazuh-elastic-sovereign-vciso-control-plane)

Start by inspecting the rule tags schema and the core repository's rule management, validation, testing, lib, and CI/CD paths. Define the scope and representation for compliance controls, asset criticality, and FAIR metadata, then verify that schemas and validation accept the agreed fields and tags.

Written by the indexing model from the issue text.