Production/admin CORS review and hardening

## User Story
In order to reduce cross-origin exposure risk and address recurring scan findings, the Data.gov team wants production and production-admin endpoints to use intentionally scoped CORS behavior.

## Acceptance Criteria
- [x] GIVEN an in-scope production or production-admin endpoint returns CORS headers \
WHEN the endpoint configuration is reviewed \
THEN the allowed origin behavior is documented as required, intentionally public, or needing restriction

- [x] GIVEN an endpoint supports credentialed browser requests \
WHEN its CORS policy is reviewed \
THEN it does not use an unsafe wildcard origin configuration for credentialed access

- [x] GIVEN an endpoint does not require cross-origin browser access \
WHEN its response headers are reviewed \
THEN unnecessary CORS headers are removed or restricted

- [x] GIVEN remediation decisions are complete \
WHEN this ticket is updated \
THEN each in-scope endpoint is marked as fixed, accepted with rationale, or moved to a linked follow-on issue

- [x] GIVEN remediation has been deployed for any changed endpoints \
WHEN verification is completed \
THEN evidence is added to this ticket

## Background
This ticket is part of a broader effort to clean up recurring low/medium web security findings across Data.gov systems by focusing on high-value fixes and reducing repeated scan noise through shared hardening.

This ticket is intended to address recurring **Misconfigured Access-Control-Allow-Origin Header** findings, especially on production and admin surfaces where browser-based cross-origin behavior may matter more.

Examples from the monthly scan that should be reviewed first:
- `https://inventory.data.gov/` (Production)
- `https://catalog-prod-admin-datagov.app.cloud.gov/` (Production)
- `https://ssb-solrcloud-gsa-datagov-management.app.cloud.gov/` (Production)

Related non-production endpoints may be reviewed separately, especially if a shared configuration pattern is discovered.

Reminder to future us:
- The point of this ticket is to determine whether these are real cross-origin exposure issues, shared config defaults, or acceptable behavior on public endpoints.
- Do not assume every scanner-reported CORS issue is equally risky.
- When remediation/analysis is complete, notify **Nina (ISSO)** so findings can be revalidated or documented appropriately.

## Security Considerations ([required](https://nvd.nist.gov/800-53/Rev4/control/CM-4))
CORS behavior can affect whether browser-based applications from other origins can read responses or make credentialed requests. Security considerations include:
- preventing overly broad cross-origin access on authenticated or administrative endpoints
- ensuring wildcard origins are not used unsafely with credentials
- preserving legitimate public API behavior where intentionally designed
- documenting accepted configurations where the scanner result is low risk or expected

## Sketch
- Inventory current CORS headers for each in-scope endpoint
- Determine whether each endpoint:
- is public or administrative
- uses cookies or other browser credentials
- truly requires cross-origin access
- Classify each result as:
- valid and intentionally public
- needs restriction
- scanner noise / low-risk accepted configuration
- Tighten configuration where needed
- Capture endpoint-by-endpoint decisions in the ticket

## Assign to Sue when Done
- [ ] Notify Nina when ready for validation/rescan