Cleanup UI package resolution

Is your feature request related to a problem? Please describe.

The UI package configuration contains several outdated or potentially misleading dependency-management practices:

• package.json contains stale resolutions for nth-check and node-sass/**/ip. None of nth-check, node-sass, or ip is present in the current lockfile. Additionally, resolutions is primarily a Yarn mechanism, while this project uses npm.
• Several dependencies use the unbounded version specifier "latest":
  • @vitejs/plugin-react-swc
  • vite-plugin-svgr
  • vite-tsconfig-paths
  • jsdom
• @types/node, @types/react, and @types/react-dom are declared in both dependencies and devDependencies, although they are build-time dependencies.
• UI automation uses npm install despite the repository committing a package-lock.json. This permits dependency resolution to differ from the committed lockfile and may hide
  inconsistencies between package.json and the lockfile.
• The declared Node.js requirement is >=21.0.0. Node.js 21 was a non-LTS release and is end-of-life, while the UI build workflow currently uses Node.js 24.

These issues reduce build reproducibility and make the package configuration harder to understand and maintain.

Describe the solution you'd like

Apply a small, non-breaking dependency-hygiene cleanup to the UI project:

1. Remove the obsolete resolutions block after confirming the referenced packages are no longer present in the dependency tree.
2. Replace the four "latest" specifications with the versions currently resolved by package-lock.json, so this cleanup does not unintentionally upgrade them:
   • @vitejs/plugin-react-swc
   • vite-plugin-svgr
   • vite-tsconfig-paths
   • jsdom
3. Retain @types/node, @types/react, and @types/react-dom only in devDependencies.
4. Replace npm install with npm ci in deterministic CI/build automation, beginning with the UI test step in .github/workflows/build_docker_images.yml.
5. Review the UI deployment script separately and use npm ci there as well if it does not intentionally need to modify dependency resolution.
6. Update the Node.js engine declaration to reflect the project’s supported LTS runtime, aligned with CI—for example, Node.js 22 or later, subject to the project’s runtime-support
   policy.
7. Regenerate and commit package-lock.json, then run the existing lint, TypeScript/build, and unit-test checks.

Safe patch-level transitive dependency updates may be included if they are produced by a controlled lockfile regeneration and pass the existing checks. The React Router major-version
upgrade should not be included in this work.

Describe alternatives you've considered

• Leave the configuration unchanged because the current lockfile generally makes installations repeatable. This retains misleading and ineffective entries and allows "latest"
  dependencies to change unexpectedly when npm install regenerates the lockfile.
• Upgrade all outdated UI dependencies simultaneously. This was rejected because several available updates are major versions that require dedicated migration and validation work.
• Keep using npm install in automation. This is useful for updating dependencies but is less appropriate for CI and deployment, where installation should reproduce the committed
  lockfile exactly.
• Keep the existing Node.js engine declaration. Although current CI satisfies it, an end-of-life non-LTS version is not a useful baseline for communicating supported environments.

Additional context

This work should be limited to dependency hygiene and reproducibility. It should not include major-version migrations such as:

• React Router 7
• React 19
• Redux Toolkit 2
• newer MSAL major versions
• RJSF 6
• Vite 8
• replacement of Moment.js

Those changes should be assessed and tested independently.

The existing UI unit tests, linting, and production build should pass after this cleanup. The project currently lacks comprehensive browser-level UI tests, so avoiding intentional
runtime behavior changes is particularly important.

Start with the UI package.json and package-lock.json to verify the resolutions, resolved versions, type dependency placement, and Node.js engine requirement. Then inspect the UI step in .github/workflows/build_docker_images.yml and the existing deployment script before changing install commands. Done means deterministic installs, a regenerated lockfile, and passing the existing lint, TypeScript/build, and unit-test checks.