Cache endpoint health as a ranked rollup

Fleet ranked endpoints by raw critical-event counts, so a machine with a
noisy but harmless event log outranked one with a mapped drive down or a
blocking service stopped. Volume is not severity, and the aggregation ran
across the whole fleet on every page load.

Rank operational blockers above degraded conditions above event noise, and
cache the verdict per asset so Fleet reads a row instead of recomputing 48h
of history. Transitions are written only when a verdict changes, capped at
50 rows per asset.

Absence of a policy binding must never suppress a verdict: drives and events
are not policy-gated, and services fall back to a built-in default impact
when no mapping applies. Event 1001 drops to informational because the WER
bucket pairs with 1000 and double-counted every crash.

Parallelize the Fleet first-paint loaders that were awaiting serially.

plugins/endpoints/eventcatalog.py

@@ -29,8 +29,15 @@ EVENT_CATALOG = {
     # code) and is the one that says what actually broke; 1001 is the WER bucket
     # record Windows writes alongside it; 1002 is a hang rather than a crash, so
     # it is a warning - the app is unresponsive, not gone.
+    #
+    # 1001 is deliberately NOT critical. Windows writes it ALONGSIDE 1000 for the
+    # same crash, so counting both double-counted every fault: a box with 2200
+    # crashes reported "Application crash x4400". It also won the dominant-event
+    # tie often enough to displace 1000, which is the record that actually names
+    # the faulting module. Kept curated so the history panel still shows it, but
+    # it no longer drives the fleet health verdict - 1000 speaks for the crash.
     1000: ('Application error', 'critical', 'Application'),
-    1001: ('Application crash', 'critical', 'Application'),
+    1001: ('Application crash', 'info', 'Application'),
     1002: ('Application hang', 'warning', 'Application'),
 }