`ImmutableCollections$SetN.probe()` slowdown suggests hot inner loop with Set operations

During analysis of two heapdumps shared [here](https://github.com/eclipse-pde/eclipse.pde/pull/2253#issuecomment-4054961583) the following issue was discovered as a hotspot that can benefit from optimization:

### Performance Data

| Metric | WITH transitive | WITHOUT transitive | Ratio |
|--------|----------------:|-------------------:|------:|
| SetN.probe() self time (µs) | 23,483,483 | 5,370,299 | **4.4×** |

### Description

`ImmutableCollections$SetN.probe()` is the internal method used by `Set.of(...)` immutable sets for `contains()` checks. The 4.4× slowdown (23.5 seconds!) indicates that some hot loop is checking membership in an immutable set far more frequently with transitive dependencies.

This likely comes from module system-related lookups (checking if a module name is in a set of known modules, or if a package is in a set of accessible packages). The `Set.of()` probe uses linear probing and can degrade with hash collisions.

### Suggested Fix

1. **Identify the caller** via a more detailed profile with call tree attribution. The callers are likely in `ModuleBinding`, `ModulePathEntry`, or module access checking code.
2. If the set is large, consider using `HashSet` instead of `Set.of()` — `ImmutableCollections.SetN` uses a flat array with linear probing, which degrades for larger sets (> ~30 elements). `HashSet` uses chaining and performs better at scale.
3. Cache the result of frequent `contains()` checks if the same elements are looked up repeatedly.