refactor: deploy CDA UI and API as separate WARs

[krowvin]

Summary

This is a stacked comparison PR against #1871 following @MikeNeilson's suggestion to investigate the OpenDCS-style two-WAR deployment.

• package the React UI as cwms-data-ui-<version>.war and the API as cwms-data-api-<version>.war
• deploy the UI as ROOT.war at / and the API as cwms-data.war at /cwms-data
• keep SPA fallback/status handling inside the UI application so known browser routes refresh with 200 while unknown routes remain 404
• point UI API and authentication requests at the separate /cwms-data application
• publish both WARs in releases and include both in the existing Tomcat container image
• route both root UI traffic and /cwms-data API traffic through the local compose setup

Deployment impact

Districts consuming release artifacts would install and manage two WARs instead of one. That may work well with the new update script because the UI and API are independently packaged, but it is an operational tradeoff we should compare with #1871's single-WAR approach. As Mike noted, production and test will also need WAF routing for the root UI application.

Verification

• gradlew :cda-gui:test :cda-gui:checkstyleMain :cda-gui:checkstyleTest :cda-gui:war :cwms-data-api:war :cwms-data-api:prepareDockerBuild
• npm test, npm run lint, and npm run format:check in cda-gui
• clean production Docker image build from a Git worktree
• launched the image against the local CWMS Oracle fixture
• browser-loaded and refreshed /swagger-ui; the OpenAPI document loads from /cwms-data/swagger-docs with no console errors
• all known UI routes return 200 for GET, and /swagger-ui returns 200 for HEAD
• unknown UI routes and non-GET UI requests return 404 and render the UI's 404 page
• /cwms-data/swagger-docs, /cwms-data/offices, /cwms-data/timezones, and /cwms-data/units return 200
• an unknown /cwms-data endpoint remains 404