[Rule Tuning] Elastic Defend and Network Security Alerts Correlation

### Link to Rule

https://github.com/elastic/detection-rules/blob/0b19e0f459dc88552291a67608fc23f85878841f/rules/cross-platform/multiple_alerts_elastic_defend_netsecurity_by_host.toml

### Rule Tuning Type

Data Quality - Ensuring integrity and quality of data used by detection rules.

### Description

Suricata alerts excluded from correlation logic in `multiple_alerts_elastic_defend_netsecurity_by_host`.

Suricata events (`data_stream.dataset == "suricata.eve"`) are included in the initial `WHERE` filter but are silently dropped in the subsequent `eval` logic that extracts the source IP.

The `CASE` expressions only handle three datasets:
- `panw.panos` and `fortinet_fortigate.log` → mapped to `fw_alert_source_ip`
- `endpoint.alerts` → mapped to `elastic_defend_alert_host_ip`

Suricata matches none of these conditions, so both variables evaluate to `null`. The `COALESCE` then returns `null`, and the following `where Esql.source_ip is not null` filter drops all Suricata events before they ever reach the `stats` aggregation.

As a result, Suricata alerts **never contribute** to the multi-source correlation logic, making the initial `WHERE` inclusion of `suricata.eve` effectively dead code.

## Fix

Add `suricata.eve` to the `fw_alert_source_ip` case expression (or introduce a dedicated variable) so that `source.ip` is properly extracted and Suricata events survive into the aggregation:

```sql
| eval fw_alert_source_ip = CASE(
data_stream.dataset in ("panw.panos", "fortinet_fortigate.log", "suricata.eve"), source.ip,
null),
```

### Example Data

_No response_