[Security Solution][Detection Engine] make building alert ancestors type safe for ES|QL rule

[vitaliidm]

Describe the bug:
Reproduced in 8.16+

https://github.com/elastic/kibana/blob/8.16/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/factories/utils/build_alert.ts#L154

There is a casting for ALERT_ANCESTORS property("kibana.alert.ancestors") into array in buildAncestors function. This is not a safe operation.
If this value appears to be not array, rule execution would fail.

  const existingAncestors: AncestorLatest[] =
    (getField(doc, ALERT_ANCESTORS) as AncestorLatest[] | undefined) ?? [];
  return [...existingAncestors, newAncestor];

We need to avoid casting here and check whether existing ancestors is an array before creating new array.
Otherwise it might lead to rule failure: existingAncestors is not iterable

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detection-engine (Team:Detection Engine)

[vitaliidm]

turned out, issue is a way how ES|QL rule build alert.

It converts results of ESQL query into object, fetches fields of source documents and merges them.
Alerts ancestors property in this case is returned as flattened object instead of array of objects. So it can't be processed correctly.
Solution is to enable fetching document source in https://github.com/elastic/kibana/blob/8.16/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/esql/fetch_source_documents.ts#L57
Merges esql results into to it and follow the same procedure as for the rest of rule when building alert

[yctercero]

@vitaliidm do we know if we'd hit this same issue with logsDB? Will enabling this resolve it for this instance as well?

cc @marshallmain