[New Rule] Dual-signal Suricata/SnortML triage (GID 411 ML ≠ signature TP)

### Description

Propose a small pack of **network/Suricata** detection rules that encode dual-signal triage for Snort-family alerts:

1. **SnortML / GID 411 high** — ML-only path: escalate/corroborate; **do not** treat as classic signature TP or auto-contain.
2. **Classic signature high-priority classifications** (GID ≠ 411) — stronger TP candidate.
3. **Optional corroboration** — classic signature + high severity / second signal (Suricata-native; FTD EVE can follow).

**Why:** Agentic SOC and automated response over-trust ML probability scores. Elastic already has strong Suricata correlation rules; this pack adds the explicit **ML ≠ signature TP** disposition split used in Secure Firewall / SnortML operations.

**MITRE:** TA0011 Command and Control (T1071), TA0001/TA0002 as applicable.

**Data sources:** Suricata (`logs-suricata.*`) via Elastic Suricata integration. Fields: `suricata.eve.alert.gid`, `suricata.eve.alert.category` / `rule.name`, `event.kind`, `event.severity`.

**ECS:** No new ECS fields required (uses existing Suricata module fields).

**Behavior-based:** Yes — generator-id / classification based triage, not IOCs.

### Target Ruleset
network

### Target Rule Type
Custom (KQL or Lucene) and/or Event Correlation (EQL)

### Related issues or PRs
- Sister portable rules: https://github.com/SigmaHQ/sigma/pull/6237
- Splunk ESCU discussion: https://github.com/splunk/security_content/issues/4220
- EvidenceForge corpus: https://github.com/Cisco-Talos/EvidenceForge/pull/389

### References
- https://www.elastic.co/docs/reference/integrations/suricata
- https://github.com/AAH20/aegis-decision-fabric
- https://a2zsoc.com/consultation (production Gate/Prove consumer — paid pilot, not unpaid R&D)

### Redacted Example Data
```json
{"event":{"kind":"alert","module":"suricata","severity":1},"suricata":{"eve":{"alert":{"gid":411,"signature_id":100001,"signature":"SnortML possible SQLi (ML-only)","category":"Attempted User Privilege Gain"}}},"source":{"ip":"203.0.113.11"},"destination":{"ip":"10.0.0.5"}}
```

Happy to implement after maintainer feedback. CLA: will sign Elastic CLA before mergeable PR (http://www.elastic.co/contributor-agreement/).

Start by reviewing Elastic's Suricata integration and the existing Suricata correlation rules referenced in the issue. Use the listed Suricata alert fields and the redacted event to define the ML-only, classic-signature, and optional-corroboration cases. Done means the proposed network rules distinguish GID 411 from other signatures without adding ECS fields and match the requested KQL/Lucene or EQL rule type.

Written by the indexing model from the issue text.