fix: do not enable invalidation tracking in performance traces

[thomasbachem]

performance_start_trace enables disabled-by-default-devtools.timeline.invalidationTracking. On a page that invalidates style heavily, that category fills the trace buffer within a few hundred milliseconds, so the recording stops before the interaction being measured finishes, and nothing in the result says so.

The comment above the list says to keep it in sync with TimelineController.ts and Lighthouse's trace gatherer. Neither enables it: DevTools annotates it default: off, experiment: timelineInvalidationTracking, Lighthouse does not carry it at all. This drops it from the default list to match.

On the same interaction, before and after: the trace goes from covering the first 192 ms to all 1663 ms of it, dataLossOccurred stops being set on Tracing.tracingComplete, and the payload drops from 199 MB to 38 MB. The issue has a self-contained page that shows the same in stock Chrome, 219 MB with data loss against 0.6 MB without the category. The traced page also runs roughly 5x slower with the category on, so the timings that do survive are distorted.

Worth weighing before merging: the events are not dead. LayoutShiftsHandler folds their node ids into backendNodeIds, which DetailsView resolves to make the Performance panel's invalidation list clickable. No insight reads the arrays or backendNodeIds, so no tool output changes, but a trace saved with filePath and reopened in DevTools would lose its invalidations view. A default DevTools recording does not have that view either, it is experiment-gated there. If keeping it reachable from here matters, an opt-in parameter would suit better than this removal and I am happy to redo it that way.

No test covers this. The failure needs a real page under enough invalidation churn to fill the buffer, and asserting the array's contents would only restate the implementation, so I left the tests alone. Nothing currently pins the category list.

Fixes #2499