Make frontend self-hosting independent from hardcoded API host IPs

[DeepZone]

Motivation

• Remove the need to hardcode a host IP or domain into the frontend build so RouteForge can be self-hosted on arbitrary hosts or domains.
• Prefer same-origin relative API calls by default and let the frontend Nginx proxy /api to the internal backend service.
• Preserve existing API endpoints and avoid any business logic changes while keeping the project read-only.

Description

• frontend/nginx.conf added to serve the built Vite SPA from /usr/share/nginx/html and proxy /api/ to http://backend:8000/api/ and /health to http://backend:8000/health with SPA try_files fallback.
• frontend/Dockerfile updated to make VITE_API_URL build-arg optional and to copy the new nginx.conf into the runtime Nginx stage while keeping EXPOSE 80.
• docker-compose.yml and docker-compose.prod.yml cleaned to remove hardcoded 192.168.x.x entries and to stop injecting VITE_API_URL into the frontend build; backend CORS_ORIGINS now uses configurable localhost defaults.
• .env.example updated to document VITE_API_URL as optional (empty for same-origin proxy) and to provide sensible CORS_ORIGINS defaults, and README.md plus docs/operations/reverse-proxy.md were updated to document the new default networking (recommended Variant A: external proxy -> frontend:80).
• No changes were made to application business logic; frontend/src/api.ts already supported an empty VITE_API_URL and therefore remained unchanged.

Testing

• Backend unit tests ran with cd backend && pytest -q and succeeded: 73 passed.
• Frontend production build ran with cd frontend && npm run build and succeeded (Vite build completed).
• docker compose config / docker compose up could not be executed in this environment because Docker is not installed (docker: command not found).

---

Codex Task