fix(docker): configure CORS for frontend in docker-compose

[anshul23102]

Fixes #1622

The docker-compose configuration was missing CORS setup for the frontend service. Frontend runs on port 5173, API on port 8081. Without explicit CORS_ALLOWED_ORIGINS, the backend's CORS middleware would reject requests from the frontend, blocking API calls.

Fix: set SECUSCAN_CORS_ALLOWED_ORIGINS environment variable in the api service to allow requests from:

• http://localhost:5173
• http://127.0.0.1:5173
• http://frontend:5173 (Docker internal DNS)

This ensures the frontend can make API calls whether accessed via localhost, IP, or internal Docker service name.

[utksh1]

Thanks for the contribution. The Docker/CORS idea may be useful, but this PR needs to be narrowed before it can be reviewed safely:\n\n1. The PR title says fix(docker): configure CORS for frontend in docker-compose, but the diff also includes a substantial unrelated parser-sandbox / network-isolation change. Please split that into a separate PR.\n2. Add focused validation for the Docker/CORS part itself. Right now the PR does not include clear coverage proving the compose change is needed and correct.\n3. Keep this PR single-purpose: Docker/CORS only.\n\nOnce the unrelated security/parser changes are removed and the scope is clean, I’m happy to re-review this.

[anshul23102]

Thanks for the review -- done. Pushed a cleaned-up branch:

• Removed the unrelated parser-sandbox/network-isolation commit. That's now its own PR: fix(security): isolate plugin parser subprocess network #1737 (issue Security: plugin subprocess runs with no outbound network isolation #1620).
• This PR is now Docker/CORS only, rebased on latest main.
• Added testing/backend/integration/test_docker_compose_cors.py: parses docker-compose.yml directly and asserts the api service sets SECUSCAN_CORS_ALLOWED_ORIGINS covering all three ways the frontend can reach it (localhost, 127.0.0.1, and the Docker-internal frontend service name). Both tests pass.

Ready for another look.