[READ] Correlate already-fetched VMware events into one incident view.

WHEN: use this after you've pulled events for an incident from the data-source skills (vmware-monitor get_events/get_alarms, vmware-aria list_alerts/list_anomalies, vmware-log-insight log_search/log_aggregate, vmware-nsx) — feed them here to find what correlates and where to look next. Not sure which events to pull? Run list_symptom_categories first. This tool does NOT fetch anything itself.

INPUT: events = event envelopes, each {ts, source, severity, entity, text, fields} (ts may be ISO-8601, epoch seconds or millis; severity is normalised). Optional: bin_seconds (time-bin width; auto if omitted), z_threshold (spike sensitivity, default 2.0), top_n (max hypotheses, default 5).

RETURNS: {event_count, window, spikes (anomalous bins), hypotheses (ranked root-cause candidates, each with a suggested_check), next_checks (what to investigate next, including which skill/tool)}.

GOTCHAS: read-only, stateless, no network — nothing is executed. Remediation routes to vmware-aiops (single fix) or vmware-pilot (multi-step). A malformed event returns {error, hint} naming the offending index.

[READ] List the symptom categories vmware-debug recognises, each with example keywords and a suggested next check (which skill/tool to run). Takes no parameters. Use this when you don't yet know what to look at — it turns "something's wrong" into concrete investigation steps. Then gather the events those checks name and pass them to incident_timeline. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {category, example_keywords, suggested_check}. The routing table is a fixed constant, so truncated is always false and total exact — this is every category, not a page. Read-only; no network access.