400 api enhancements

[kjlippold]

Updates several parts of the data management API to improve flexibility in using the API and to better align the API with OGC specs.

1. Moves pagination metadata from response headers into the response body.
2. Renames page and page_size to limit and offset.
3. Adds new properties query parameter allowing clients to select which properties get returned in the response.
4. Adds new include query parameter allowing clients to request additional related resources in the response.
5. Removed summary/detail response shapes (replaced with properties/include).
6. Observation endpoints are no longer nested under datastreams.
7. Merged all data product transformation types into one set of transformation endpoints.
8. Moved service layer into interfaces/api app. Several validation checks that were being checked only in the service layer are now checked in models. This ensures that other points of access, such as the admin dashboard, have the same validation checks applied as the data management API.
9. Updated Python and Typescript clients, data management app, and QC app to work with the new API.

Note: These changes adopt several design paradigms used by the OGC API spec, but are still not fully compliant with the spec. Strict spec compliance will be worked on later.

[daniel-slaugh]

I spent a lot of time reading through this PR, clicking around, and pointing agents at it with directed questions. In general, everything seems to be running pretty smooth. The agents found the following issues I'd recommend looking at before submitting this:

[P1] Observation downloads can silently omit data.
The server returns an estimated totalCount for large filtered queries, but the clients use it to decide when to stop downloading. With 60,000 matching observations, an estimate of 40,000, and the UI’s 50,000-row page size, the client downloads only 50,000 and reports success. I reproduced this using the PR’s count and pagination logic. Count implementation

[P2] Task-run endpoints return HTTP 500 for advertised query parameters.
ETL, monitoring, and product run-list endpoints forward properties and include into a service that rejects those arguments. limit=0 also passes request validation but fails service validation. I verified all three validation failures; the exception handler maps them to 500. These are one API-contract bug, not separate findings. Affected forwarding

[P2] The ingestion selector allows mappings that cannot be saved.
linkedDatastreamIds is now permanently empty, so datastreams already assigned to another ingestion task appear available. Selecting one passes frontend validation, but the backend rejects its mapping because the target must be unique. The new task is saved before its mappings, so this also leaves a partially created task. Disabled selection guard

[kjlippold]

@daniel-slaugh The issues you found should be addressed now.

1. Updated hydroserverpy and hydroserver-ts to correctly treat the row count as an estimate.
2. Stopped forwarding query params not accepted by the task run service and updated exception handlers to map disallowed query params to a 400 response instead of 500.
3. Mapping and transformation endpoints are no longer nested under their respective tasks. Target datastream selectors can now fetch all transformations/mappings within a workspace in one query and filter out datastreams that are already assigned as targets from the dropdown.