[web-console][dependency] Upgrade frontend to Vue 3.5 and Vite 8 toolchain, lazy-load monaco

[czy006]

Why are the changes needed?

monaco-editor 0.49.0 -> 0.56.0:

• on-demand imports (editor.api + SQL language definition + curated editor features) replace the full entry that bundles ~90 languages
• setupMonaco() loads monaco lazily when the SQL editor mounts, so the ~1MB gzip monaco assets no longer load on app startup
• unreferenced language-service worker bundles (~9.3MB) dropped at build time

Build toolchain:

• vite 5.2.13 -> 8.2.2 (Rolldown), @vitejs/plugin-vue 6.0.8, vite-plugin-vue-devtools 8.2.1
• manualChunks -> codeSplitting.groups with the same 8 vendor groups; the monaco group sets includeDependenciesRecursively:false so a shared util cannot leak into it and re-create a static entry dependency that would defeat the lazy loading
• Node v18.18.0 -> v22.23.2 (pom.xml frontend-maven-plugin, README, package.json engines); typescript ~5.9.3 + vue-tsc 3.3.11 restore the type check that previously crashed on @vue/language-core 2.x; new "typecheck" script

Measured (vs the pre-upgrade build):

• build time 15.88s -> ~1.7s; dist 7.8MB -> 7.1MB; 114 -> 30 JS chunks
• monaco removed from the startup path; ~90 unused language chunks eliminated

Verified: mvnw package -pl amoro-web (frontend-maven-plugin with the pinned Node 22: pnpm install + vite build + gen:license) passes; eslint clean on all changed files; vue-tsc runs with no new errors (remaining findings are pre-existing in untouched files); vite dev with mock server smoke-tested.

Brief change log

• vue 3.4.27 -> 3.5.41, vue-router 4.3.3 -> 5.2.0, pinia 2.1.7 -> 4.0.3 (+ @vue/devtools-api peer), vue-i18n 9.13.1 -> 11.4.9
• ant-design-vue 4.2.3 -> 4.2.6, dayjs/axios/swagger-ui minor bumps
• echarts 5.5.0 -> 6.1.0 with the official v5 compatibility theme registered to keep the current chart appearance
• vue-virtual-scroller 2.0.0-beta.8 -> 3.0.5 (stable); CSS entry moved to index.css, RecycleScroller usage unchanged

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)