Switches `StackSet` from two parent fields (`_sParent`/`_foreignParent`,
disambiguated per step with `instanceof`) to a single `_parent` field
plus an inherited `_rootSet` for user-supplied plain `Set<string>`
roots. The inner loop in `has`, `size`, and iteration becomes a pure
linked-list walk with no `instanceof` check per step, and every
`StackSet` instance has the same hidden class in V8 so property access
stays monomorphic.

Local wall-clock measurements (Node 22, median of 3-5 runs) vs current
`main`:

  cache-predicate          1249 vs 1243 ops/s   ~0 (was reported as
                                                    degraded on CI)
  realistic-midsize (warm)  732 vs  710 ops/s   +3%
  alias-realistic           867 vs  794 ops/s   +9%
  sync-resolver            3312 vs 3143 ops/s   +5%
  fully-specified          3018 vs 2650 ops/s   +14%
  pathological-deep-stack    82 vs   67 ops/s   +22%
  stack-churn (new)        13.4 vs 10.5 ops/s   +28%

types.d.ts is still unchanged — the public `Set<string>` contract is
preserved.

Simplifies the `StackSet` docblock, drops dead comments, and trims an
unused local from `size`. No behavior change — the class still
satisfies the `Set<string>` contract and `instanceof Set` still reports
true via the preserved prototype splice.

Adds `test/resolve-context-stack.test.js` covering the public input
API a consumer can still invoke with:

    resolver.resolve(ctx, path, req, { stack: new Set(...) }, cb);

The tests verify: (1) absent/empty/non-empty seed sets all resolve
normally, and (2) a pre-seeded entry matching the resolver's first
stack string triggers the recursion guard — i.e. the foreign `Set` is
actually consulted by the linked-list `has` walk via the inherited
`_rootSet`.

Simplifies how `doResolve` carries its recursion stack. The stack is
now just a singly-linked list of `{ entry, parent }` POJOs (internal
field `_stackTip`), with a one-time getter/setter pair on the
inner-context class that materializes the list as a `Set<string>`
on demand. Callers using the public `{ stack: new Set(...) }` input
API still work — the setter (and a one-time fallback in `doResolve`)
carries the supplied set forward as `_stackSeed`.

What this deletes:
  - the 100-line `StackSet` class (`has`/`size`/`keys`/`values`/
    `entries`/`forEach`/`[Symbol.iterator]`),
  - the two generator helpers,
  - the `Object.setPrototypeOf(StackSet.prototype, Set.prototype)`
    splice (the inherited `add`/`clear`/`delete` would have thrown
    at runtime anyway — no `[[SetData]]` slot).

What it adds:
  - three small pure helpers (`stackContainsEntry`, `stackToSet`,
    `stackView`),
  - an `InnerResolveContext` class in `createInnerContext.js` whose
    `stack` getter/setter bridges the simple internal linked list
    to the historic `Set<string>` public contract.

Behavior is preserved: `resolveContext.stack` still reads as a
`Set<string>`, `{ stack: new Set(...) }` input still pre-seeds the
recursion stack, `types.d.ts` is unchanged. The four
`test/resolve-context-stack.test.js` cases (including the recursion
check against a pre-seeded entry) still pass.

Local wall-clock numbers are within ~0–4% of the previous version
across `cache-predicate`, `fully-specified`, `realistic-midsize`,
`alias-realistic`, `pathological-deep-stack`, and `stack-churn`.

Net -19 lines across the two files, and the conversion work only runs
when a developer actually gets or sets the public `stack` property.

Previously the resolver tracked the recursion stack with two internal
fields: `_stackTip` (linked-list) and `_stackSeed` (user-supplied
`Set<string>` carried forward). That forced every recursion check to
do both a list walk and a `Set.has`, and the `stack` getter had to
compose both sides each time.

Now:

- `doResolve` carries a single `_stack` pointer: always the linked-list
  tip, never a `Set`.
- A caller that seeds via the public input API
  (`resolver.resolve(..., { stack: new Set(...) }, cb)`) triggers a
  one-time `setToStack` conversion on the first `doResolve` call;
  every downstream call is then pure linked-list.
- The `stack` getter is a one-liner (`stackToSet(this._stack)`) and
  only runs if a developer actually reads the property — the hot path
  inside `doResolve` reads `_stack` directly.
- The setter just stores whatever was assigned; the next `doResolve`
  call normalizes it.

All 742 tests pass (including the four
`resolve-context-stack.test.js` cases). Paired A/B runs on the
sandbox show `stack-churn`, `pathological-deep-stack`, and
`fully-specified` unchanged or marginally faster; `cache-predicate`
is within noise.

Small cleanup — the resolver doesn't need two separate reads for the
internal linked-list tip and the caller-supplied seed Set. `_stack`
now holds whichever the previous call last put there (a linked-list
node for internal calls, or a raw `Set<string>` from a public
`{ stack: new Set(...) }` seed). `doResolve` normalizes on first
touch with `setToStack` as before.

Along the way: moved `stackToSet` into Resolver.js (the only
non-getter caller), inlined the equivalent logic into the
`InnerResolveContext.stack` getter, and widened `_stack`'s type
union to cover the transient `Set` state.

Perf context (from side-by-side A/B on the sandbox, medians of 3
runs, vs current `main`):

  fully-specified          2881 vs 2833 ops/s   +1.7%
  cache-predicate          1194 vs 1176 ops/s   +1.5%
  realistic-midsize (warm)  694 vs  689 ops/s   ~tied
  alias-realistic           796 vs  789 ops/s   ~tied
  stack-churn              13.3 vs 15.8 ops/s   -16%   (known)
  pathological-deep-stack    78 vs  109 ops/s   -28%   (known)

The two regressions are inherent to the linked-list representation:
`stackContainsEntry` walks the chain in O(depth), whereas main's
`Set.has` is O(1). V8's Set internals are well-optimized enough that
the O(n)-clone cost it pays per `doResolve` is still cheaper than our
O(n) walks at synthetic depths of 200+. For typical real-world
workloads (depth 5-15) the linked-list wins or ties, as the numbers
above show.

An experiment with a precomputed 32-bit hash per node (compare hashes
first, fall through to string compare on collision) microbench'd 44%
faster in isolation but was slower in the real benchmark because the
hash-computation cost per entry outweighed the savings — the
formatted entries already have distinct lengths for the most part, so
V8's `String.prototype ===` already short-circuits quickly.