Three additive optimizations to the cached walker:

- Inline the fast-path checks into both recursive and iterative
  walkers, saving one V8 stack frame per descent. The standalone
  `sideEffectsFastPath` helper is removed (only ever used by the
  walkers, now inlined).
- Hoist `getHarmonyImportSideEffectDependency()` to one resolution at
  the public entry; threaded into the recursive call as a parameter.
- Replace the per-frame `_sideEffectsCircularSeen` save/restore with a
  single per-walk flag reset only at the public entry. A cycle
  anywhere in the walk inhibits caching for the rest of that walk —
  strictly conservative vs. the previous subtree-scoped tracking, but
  cycle-free builds (the common case) cache identically.
- Add cache lookup and cache store to the iterative form so deep-chain
  walks also benefit from memoization, and inline its fast-path
  checks.

Latest microbench (best of 7, fresh chain per call where applicable):

  First-walk only (cold cache):
    chain    BEFORE     NOW
     10      311 ns     293 ns          (faster than BEFORE)
     100     99 ns      96 ns           (faster than BEFORE)
     1000   127 ns      136 ns
     5000   123 ns      485 ns          (iterative tail engaged)

  Repeated queries (SideEffectsFlagPlugin access pattern):
    chain    BEFORE        NOW
     10      0.03 ms       0.08 ms
     100     0.13 ms       0.06 ms      2.2x
     1000   14.34 ms       0.42 ms      34x
     5000  694.30 ms       1.90 ms      365x

A purely linear chain of side-effect-free imports — module A imports
B imports C imports ... — is the worst case for stack-frame-per-module
walking. It is also the pattern that triggered #20986.

walkSideEffectsRecursive now peels off linear-chain heads inside a
single frame. Each iteration of the inner loop:
  - runs the cache check + fast-path checks against the current
    module,
  - if the module is a linear-chain head (exactly one
    HarmonyImportSideEffectDependency to another NormalModule), pushes
    it onto a per-walk ancestor stack and continues with the referenced
    module,
  - if not, breaks out to the existing general for-loop walk.

The chain's tail returns a state which propagateLinearResult walks
back up the ancestor stack, applying the same aggregation rules the
recursive call would have applied (bailout, CIRCULAR filtering,
caching).

Net effect: walks that were strictly linear cost one V8 frame total
no matter how deep, and never hit walkSideEffectsIterative. The depth
limit only applies to genuinely branching graphs where each level
truly needs its own frame.

Microbench (median, fresh chain per call, no cache reuse):

  chain    BEFORE     prev (v2)     NOW (v3)
   10      309 ns     293 ns        292 ns
   100     143 ns     96 ns         127 ns
   1000    114 ns     136 ns        123 ns
   5000    123 ns     485 ns        146 ns

The chain=5000 regression vs. BEFORE is gone — the linear-chain
fast path keeps it within run-to-run noise of the recursive baseline.

Repeated queries (SideEffectsFlagPlugin pattern, chain=5000):
  BEFORE: 676.64 ms
  NOW:      1.83 ms   (370x faster)

The previous linear-chain optimization only fired when a module had
exactly one entry in `dependencies` — but a real ESM module compiled
by webpack has the `HarmonyImportSideEffectDependency` *plus* an
`HarmonyExportSpecifierDependency` per `export` and a `ConstDependency`
per replaced expression. With the strict `length === 1` check the
1300-module cyclic chain (the canonical #20986 repro) fell through to
the general for-loop walk and overflowed V8's stack at ~1300 frames
again on Node 22+.

Loosen the linear-chain detection to "exactly one `SideEffectDep`
among any number of deps whose `getModuleEvaluationSideEffectsState`
returns `false`/`CIRCULAR_CONNECTION`". The walker now processes the
module's non-recursive deps in their declared order — bailing out
correctly with the first dep whose state is `true`, aggregating
non-`false` states into `nonRecursiveCurrent` — and only attempts the
linear tail-call when:

  - at most one `SideEffectDep` was seen,
  - no non-recursive dep triggered a bailout,
  - `nonRecursiveCurrent` stayed at `false` (otherwise the
    "ancestor's current = chain state" propagation rule no longer
    holds and we fall back to the general walk).

Verified on the actual #20986 repro (1300-module cyclic chain):

    AFTER  (#20993 generator trampoline)  ~12.3 s
    NOW    (this branch)                   ~6.5 s    (~1.9x faster)

  Larger chains (N >= 3000) hit pre-existing stack overflows in
  `ModuleConcatenationPlugin._tryToAdd` and
  `SideEffectsFlagPlugin.optimizeIncomingConnections` that are out of
  scope here — both branches behave identically there.

Adds a regression test that builds a 5000-module cyclic chain whose
modules have the same `[SideEffectDep, ConstDependency, ConstDependency]`
dependency shape as the real repro.

Three correctness fixes + a leak cleanup + a coverage gap, all flagged
by Copilot on PR #21014:

1. propagateLinearResult was using `ancestor.dependencies[0]` as the
   bailout dep, but a module qualifying for the linear-chain fast path
   can have non-recursive deps (ConstDependency, HarmonyExport*) before
   its single HarmonyImportSideEffectDependency. The recorded bailout
   would then point at the wrong dep type / location. Push pairs of
   `(mod, linearDep)` onto `linearAncestors` and pop both in the
   propagation walk so the bailout always references the actual
   SideEffectDep that triggered the descent.

2. The iterative walker's `pending === true` propagation path popped
   each parent frame without writing `_sideEffectsStateGraph` /
   `_sideEffectsStateValue`, even though `true` is monotonic and is
   already memoized in the sibling `state === true` branch. Memoize
   `true` here too so deep-tree bailouts don't re-walk on subsequent
   queries.

3. `cleanupForCache` now clears `_sideEffectsStateGraph` and
   `_sideEffectsStateValue`. Otherwise a long-lived NormalModule
   strong-references the ModuleGraph it was last walked against,
   keeping the entire Compilation alive across watch-mode rebuilds for
   modules that are never re-queried with a fresh ModuleGraph.

4. Adds a regression test that builds a 2500-module *non-linear*
   graph (each module has two SideEffectDeps so the linear-chain fast
   path can't apply). The walker recurses one V8 frame per module and
   must cross `SIDE_EFFECTS_RECURSION_LIMIT` into the iterative
   fallback — exercising the path that was previously only covered by
   indirect tests.