fix: return 200 for CDA GUI client routes

[krowvin]

I had been sitting on this branch for a minute and thought I would go ahead and PR it.

See Daniel's reported issue for details

• Swagger page returns 404 but loads anyway #1687

Infra was setup i believe to support having CDA's UI and API being split.

instead of
https://cwms-data.usace.army.mil/cwms-data being the UI and API

https://cwms-data.usace.army.mil -> UI
https://cwms-data.usace.army.mil/cwms-data -> API

Additional comment added below.

Summary

• return HTTP 200 when known CDA GUI routes are served through the React client-side routing fallback
• preserve the existing 404 status for unknown paths and non-page requests
• support alternate CDA deployment context paths and trailing-slash navigation

Root Cause

Tomcat routes missing static resources through the 404 error-page mapping to index.html. The React app therefore renders successfully, but the original 404 status remains on the response. Reverse proxies and web crawlers treat that successful page as missing.

The new error-dispatch filter changes the status only for known GUI GET and HEAD routes. API and unknown-route 404 behavior is left intact.

Related Issue

Closes #1687

Validation

• ./gradlew :cwms-data-api:test --tests 'cwms.cda.servlet.SpaErrorStatusFilterTest' — 13 passed
• ./gradlew :cwms-data-api:checkstyleMain :cwms-data-api:checkstyleTest :cwms-data-api:test --tests 'cwms.cda.servlet.SpaErrorStatusFilterTest' — passed; the new files have no Checkstyle findings
• ./gradlew build — compilation, GUI build, WAR packaging, and 745 tests passed; the test task failed on 9 existing Mockito failures under local JDK 21 while mocking generated/final classes
• Integration tests were not run because this routing change does not require Oracle/CWMS infrastructure

Checklist

• AI tools used

[MikeNeilson]

Add @WebFilter (I think, look at the other filters for the right annotation) and remove the web.xml change.

Unless there's a specific reason to configure it in the web.xml instead. That recommendation is likely left over from all the examples that existed before annotations were supported in Java.

[krowvin]

@MikeNeilson I had initially planned to go in this direction, but I pushed up this older idea for handling the routing before our group had landed on splitting the UI and the API.

Would you be okay with me updating this PR, opening a new PR, or opening a PR against this PR with a new proposed method for splitting the two? One possibility is to produce two independently deployed WARs/applications: one for the UI and one for the API.

That could require districts to install and manage two different WARs. Would that separation be a better option now that we have the new update script, or would the additional deployment be more trouble than it is worth?

[MikeNeilson]

@MikeNeilson I had initially planned to go in this direction, but I pushed up this older idea for handling the routing before our group had landed on splitting the UI and the API.

Would you be okay with me updating this PR, opening a new PR, or opening a PR against this PR with a new proposed method for splitting the two? One possibility is to produce two independently deployed WARs/applications: one for the UI and one for the API.

That could require districts to install and manage two different WARs. Would that separation be a better option now that we have the new update script, or would the additional deployment be more trouble than it is worth?

Hmm, might be more trouble than it's worth, but reasonable to investigate. Would want them both as WARs to easy the packaging but we'll see how much of a problem it is in the docker compose setup and tests, oh look at how OpenDCS does it. they are separate there. so yeah not a huge deal.

I think we'll need a WAF change in prod and test, but that's not a huge deal if we know it's coming.