perf(ext/web): lazy-init EventTarget listeners table - #33734

Substance is right and well-targeted — AbortSignal is the dominant short-lived EventTarget subclass, and walking the dispatch path confirms lazy init is safe end-to-end:

• AbortSignal.signalAbort → runAbortSteps short-circuits to listenerCount(this, "abort") > 0 before allocating an Event or calling dispatchEvent — and listenerCount reads through target?.[eventTargetData]?.listeners ?? {} which already returns 0 for the lazy-undefined case (02_event.js:898–908). So no listener-attached signal never allocates the event, the listeners table, or runs dispatchEvent. ✓
• defineEventHandler's setter calls this.addEventListener(name, ...) (02_event.js:1482), which is the lazy-init trigger — so socket.onopen = ..., signal.onabort = ..., etc. correctly populate eventTargetData before any async event arrives.
• All five getter helpers (getAssignedSlot/getHasActivationBehavior/getHost/getListeners/getMode/listenerCount) already use target?.[eventTargetData]?.X — confirmed; they handle undefined data without modification.
• Node compat (_events.mjs:986) already handles if (!data) returning new SafeMap(). ✓
• setEventTargetData callers (02_websocket.ts:92, 13_message_port.js:116, 01_webgpu.js:892, 99_main.js:966) all eagerly init via webidl.createBranded paths, so server-upgraded WebSockets, MessagePorts, WebGPU types, and globalThis are unchanged. ✓
• JS-constructor subclasses (AbortSignal, WebSocket public ctor, BroadcastChannel, FileReader, EventSource, Performance) all call super() → empty new constructor → first addEventListener lazy-inits.

Blocker — lint failing

error[no-unused-vars]: `listeners` is never used
  --> ext/web/02_event.js:1077:13

In dispatchEvent:

const data = self[eventTargetData];
if (data === undefined || !data.listeners[event.type]) {
  setTarget(event, this);
  return true;
}
const { listeners } = data;        // <-- never used after

if (getDispatched(event)) { ... }
if (event.eventPhase !== Event.NONE) { ... }
return dispatch(self, event);

The original code's const { listeners } = self[eventTargetData]; was used only for the !listeners[event.type] early-return — the rest of the function delegates to dispatch(self, event), which re-fetches self[eventTargetData].listeners internally. The PR ports the early-return correctly, then leaves a stale const { listeners } = data; that was never needed. Just delete that line:

const data = self[eventTargetData];
if (data === undefined || !data.listeners[event.type]) {
  setTarget(event, this);
  return true;
}

if (getDispatched(event)) { ... }

Lint failures on three platforms gate the rest of the build (debug/test jobs are pending). Fixing this unblocks CI.

Non-blocking

removeEventListener style nit

const data = self[eventTargetData];
if (data === undefined || callback === null || !data.listeners[type]) {
  return;
}
const { listeners } = data;

This is fine — listeners IS used after, for the actual removal loop. Just noting it for symmetry with the dispatchEvent fix above; don't apply the same delete here.

addEventListener lazy-init pattern

let data = self[eventTargetData];
if (data === undefined) {
  data = self[eventTargetData] = getDefaultTargetData();
}

The two-step data = self[...] = ... works but reads slightly awkwardly. The ??= form would be one operator (assuming the V8 fast path for ??= on object properties is comparable):

self[eventTargetData] ??= getDefaultTargetData();
const { listeners } = self[eventTargetData];

The PR description even describes the fix this way ("self[eventTargetData] ??= getDefaultTargetData()"). Stylistic only — current form is correct. If V8's ??= codegen for own-properties is materially worse than the explicit branch, ignore.

CI

3 lint failures, 25 jobs pending. Substance + manual walkthrough is clean — once the unused listeners destructuring is removed and lint goes green, I'd expect this to land cleanly. Holding REQUEST_CHANGES on the lint-blocking dead-line.

Nice improvement