fix: restore sass devDependency for vue2 webviews

Description

npm run build:browser fails on a clean install (on the branch for this MR chore(deps): update dependency @semantic-releas... (!2923 - closed)) with:

[vite:css] Preprocessor dependency "sass" not found. Did you install it?
file: webviews/vue2/gitlab_duo_chat/src/App.vue?vue&type=style&index=0&lang.scss

sass and sass-loader were accidentally dropped from webviews/vue2/package.json's devDependencies in 678e5406 (Feb 2024, "chore: set up testing framework for chat webview"), even though App.vue and other components still use <style lang="scss">.

Since then, sass only existed in webviews/vue2/package-lock.json as an unmet optional peer dependency of vite ("optional": true, "peer": true). npm does not install optional peer deps unless something else in the tree requires them directly, so a genuinely fresh npm ci/npm install in webviews/vue2 never installs sass. Anyone with a stale node_modules (left over from before Feb 2024, or from a different install path) wouldn't hit this until they reinstalled from scratch.

This re-adds sass as an explicit devDependency and regenerates the lockfile so it's a normal direct dependency instead of an unresolved optional peer.

Related Issues

No linked issue — found while debugging a local npm run build:browser failure that looked related to an unrelated dependency-bump commit but was actually caused by this pre-existing, latent lockfile issue.

How has this been tested?

• Reproduced the failure with a clean npm ci in webviews/vue2 using the main lockfile (before this fix).

• Applied the fix, ran npm install --package-lock-only to regenerate the lockfile, then npm ci in webviews/vue2 — confirmed sass is installed as a direct dependency (no longer optional/peer in the lockfile).

• Ran npm run build:browser from the repo root end-to-end — completes successfully (chat, security_finding, and issuable webviews all build).

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.

• Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

N/A

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes