feat(ext/node): emit perf_hooks PerformanceEntry for http2 sessions and streams - #33618

The implementation is well-structured. Three coordinated pieces:

1. Rust frame counters: frames_received / frames_sent incremented in the nghttp2 on_frame_recv_callback / on_frame_send_callback, exposed via #[fast] #[smi] fn frames_received/sent() ops. Counter type is u32 with saturating_add so it won't panic on overflow at the cost of saturating after 4B frames — fine for any reasonable session.
2. JS perf-entry plumbing: kPerfStats / kPerfEmitted Symbols on each session/stream, emitSessionPerfEntry / emitStreamPerfEntry called from finishSessionClose and the stream-close path. Uses enqueuePerformanceEntry({ name, entryType: "http2", startTime, duration, detail }) matching Node's PerformanceEntry shape for http2.
3. Test enrollment alphabetically positioned correctly (padding-aligned < perf_hooks < ping-settings-heapdump).

Holding off on autonomous APPROVE for two reasons per fibibot's policy:

1. CI not yet complete — 80/n checks passing, none failed, but the relevant test node_compat debug shards on most platforms are still queued.

2. Cross-cutting infrastructure change: this PR adds two new public exports to ext/web/15_performance.js (enqueuePerformanceEntry, registerExtraEntryType) plus a module-level extraEntryTypes Set that the PerformanceObserver constructor now consults. That's not just node:http2 plumbing — it's new infra that any future polyfill (node:dns, node:http, node:net, etc.) can hook into to surface their own performance entries. Worth a maintainer's deliberate sign-off on the API shape (registerExtraEntryType global registry vs. per-observer subscription, enqueuePerformanceEntry exposing queuePerformanceEntry directly with no validation, etc.).

cc @bartlomieju on the ext/web/15_performance.js API additions — would appreciate your read on whether the extraEntryTypes registry is the right shape for general perf_hooks integration, or if the http2 case should be more contained.

Two non-blocking inline notes below.

Delta addresses my prior "no validation" concern on enqueuePerformanceEntry. Verified:

• registerExtraEntryType(type) now throws TypeError on non-string or empty-string. ✓
• enqueuePerformanceEntry(entry) validates entry is non-null object with required fields (name, entryType, startTime, duration) of the right type. Extra fields like detail pass through untouched, which matches the docstring. ✓
• TypeError is the primordial (imported at 15_performance.js:19), so the throw can't be hijacked. ✓
• Validation happens before queuePerformanceEntry, so an observer never sees a malformed entry. ✓

CI fully green: 133 SUCCESS, 0 FAILURE, 2 SKIPPED. All test node_compat × all platforms × debug+release pass.

Holding to COMMENT rather than APPROVE — same architectural escalation as my prior review. The validation patches the obvious foot-gun, but the bigger call still lives with the maintainer:

• extraEntryTypes is a global set that mutates PerformanceObserver's allowed entry types for the whole isolate. Once node:http2 calls registerExtraEntryType("http2"), every PerformanceObserver({ entryTypes: ["http2"] }) becomes legal everywhere, including in code that never touched http2.
• An alternative (per-polyfill or per-observer subscription) would scope this. Not necessarily wrong as is, but it's a one-way door for the API shape.

cc @bartlomieju — registry-shape decision is the call worth deliberately signing off.