* chore(deps): lock file maintenance

* Resolve audit

* fix: pin stacker to 0.1.23 and windows-sys to 0.59.0 in Cargo.lock

stacker 0.1.24 requires windows-sys >=0.60 which dropped windows_x86_64_gnu.
That crate provided the static import library supplying __imp_OpenProcessToken
and friends that libmimalloc-sys2 needs on windows-gnu. Pin stacker to 0.1.23
(which accepts windows-sys 0.59.x) so the arch crates are restored and the
windows-gnu build links successfully.

---------

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Lukas Taegert-Atkinson <[email protected]>

Co-authored-by: Lukas Taegert-Atkinson <[email protected]>

fix(deps): update swc monorepo

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

)

PR #5947 added "exports" to the universal RESERVED_NAMES set, which
caused every variable or parameter named "exports" to be renamed to
"exports$1" in any scope, even when no conflict exists with the output
format's runtime "exports" identifier. Because eval strings are not
rewritten, this silently broke code like:

    (unused, exports) => {
      console.log(exports.bar);
      eval('exports.bar = 1');
    }

where the parameter was renamed but the eval argument was not. The same
over-aggressive rename also applied to unrelated nested bindings in ES
output, which has no runtime "exports" at all.

This change removes "exports" from RESERVED_NAMES and restores the
system-format-specific check in ChildScope.addUsedOutsideNames so that
nested scopes in SystemJS output still treat "exports" as used when
they reference an outer exported binding. Top-level protection for
CJS/AMD/UMD/IIFE/SYSTEM output is unchanged: RESERVED_USED_NAMES in
Chunk.ts still seeds the chunk-level usedNames with "exports", and
reassigned exports still carry renderBaseName === "exports" which
propagates into nested scopes via getBaseVariableName().

The deconflictTopLevelVariables cache from PR #5947 is untouched, so
its performance benefits are preserved; a benchmark that reliably sees
the PR's generate-time speedup (~20% vs pre-PR) shows no regression
from this change.

Fixes #6357

Made-with: Cursor

Co-authored-by: Lukas Taegert-Atkinson <[email protected]>

This should be revisited from time to time.