[parity] PerformanceObserver.supportedEntryTypes reads as undefined when chained directly into a method call #8237

Split out of #6766 after PR #8229.

A static read of PerformanceObserver.supportedEntryTypes resolves correctly when it is bound to a local first, but yields undefined when the read is immediately chained into a method call.

import { PerformanceObserver } from "node:perf_hooks";

const types = PerformanceObserver.supportedEntryTypes;
types.includes("mark");                              // ✅ works

PerformanceObserver.supportedEntryTypes.includes("mark");   // ❌
// TypeError: Cannot read properties of undefined (reading 'includes')

Pinned by test-parity/node-suite/perf_hooks/global/class-constructors (last line; everything above it passes, including mark instanceof PerformanceEntry and the performance singleton identity). observer/supported-entry-types-exact, which binds to a local first, passes. Reproduce with ./run_parity_tests.sh --suite node-suite --module perf_hooks.

Where to look

crates/perry-hir/src/lower/expr_call/module_class_static.rs already carries a special case for exactly this pair:

// #1320: `PerformanceObserver.supportedEntryTypes`
// `…supportedEntryTypes.includes(x)` is a value
// … bogus NativeMethodCall(class="supportedEntryTypes").
| ("perf_hooks", "supportedEntryTypes")

so the chained shape is recognised as not being a method call on a class — but the resulting value read still comes back undefined. The static class-property read presumably needs to route to the same place the plain read does (nm_attach_perf_hooks in crates/perry-runtime/src/object/native_module/callable_exports.rs hangs the array off the PerformanceObserver class closure as a dynamic prop).

Note this is one of two regressions that appeared between the 2026-07-22 sweep and 2026-08-16 — it is not in #6766's original list of 61.