Upgrade Rspack SWC

Perform the upgrade end to end. Keep the patch focused, preserve unrelated work, and base every changelog claim on the SWC tag range.

Guardrails

• Confirm the checkout is web-infra-dev/rspack and read the applicable AGENTS.md instructions before editing.
• Inspect git status --short, the current branch, and remotes first. Never overwrite, discard, stage, or commit unrelated user changes. Stop for direction if unrelated changes overlap the files required by the upgrade.
• Use exact, stable, non-yanked crate versions. Ignore prereleases unless the user explicitly requests one.
• Treat the root Cargo.toml comment Must be pinned with the same swc versions as an invariant. Keep SWC direct dependencies on one compatible release set; do not blindly bump only swc_core.
• Treat every swc_experimental_* crate as independent and out of scope. Never query, bump, or otherwise change its manifest or lockfile version as part of this workflow.
• Keep existing default-features, feature lists, and unrelated dependency versions unchanged unless the new SWC release requires an adaptation.
• Do not edit crates/rspack_workspace/src/generated.rs by hand. Generate it with cargo codegen.
• Use official sources for release data: crates.io and swc-project/swc tags, commits, and pull requests.
• Mention an upstream bug fix in the PR description only when it matches a Rspack issue's failure mode and the fix is validated when practical. Omit plausible, weak, or unverified bug connections instead of using “related” or “may fix”.
• Use pnpm run build:binding:dev as the only validation command. Do not run tests or lint unless the user explicitly requests them.
• Do not create the PR until the intended diff and required validation have been reviewed. If validation is incomplete or an important risk remains, explain it and open a draft only when the user still wants a PR.

1. Establish the version range