The StackEntry refactor (#526) replaced the internal Set-based stack
with a singly-linked list. However, the public API still allows
callers to pass a Set<string> as resolveContext.stack. When doResolve
receives a Set as parent, Set.has(stackEntry) compares by reference
and never matches the new StackEntry object, so recursion detection
silently fails.

Fix: check `parent instanceof StackEntry` and fall back to
`parent.has(stackEntry.toString())` for Set compatibility.

https://claude.ai/code/session_01TBuEDZmTzjKYzebY26ZkL1

… set

`doResolve` runs once per plugin step (~10-15 per resolve). When
`resolveContext.log` is unset — the production hot path — the inner
context is structurally identical to the parent save for `stack`, so we
can mutate `stack` in place before the hook call and restore it after,
avoiding one options-literal + one `createInnerContext` return object
per step.

`forEachBail` and tapable's `AsyncSeriesBailHook` drive sibling calls
strictly sequentially, so no two call sites read `resolveContext.stack`
concurrently. The logging branch remains unchanged, since it still needs
the deferred header wrapper from `createInnerContext`.

Benchmark on top of main (which already has the singly-linked stack
from #526), median of 5 runs under the repo's `--no-opt --predictable`
flags:

  concurrent-batch (15 parallel resolves):  1.075 -> 1.045 ms  (+2.8%)

All 970 tests pass, including the recursion detection suite.