docs: add frontend API validation guide

[SHAURYAKSHARMA24]

Summary

Closes #132.

Adds frontend/API validation documentation for OpenShield covering the React/Vite frontend, Flask API endpoints, JWT behaviour, CORS/error handling, live mode setup, and frontend-to-backend data flow.

Changes

• Added docs/validation/FRONTEND_API_TESTING.md
• Added docs/validation/TEST_RESULTS.md
• Documented frontend page inventory
• Documented page-to-API endpoint mapping
• Documented live mode setup using VITE_API_URL and JWT token handling
• Documented expected API response shapes
• Added auth/JWT validation checklist
• Added CORS, loading, error, and empty-state validation checklist
• Added known frontend/API gaps and recommended follow-up issues
• Added structured frontend/API test results table

Validation Results

• npm install: Pass
• npm run lint: Failed — 65 lint errors, mostly unused React imports
• npm run build: Pass
• npm run dev: Pass — Vite starts on localhost:5173
• pytest: Failed — DATABASE_URL not configured for PostgreSQL-backed tests

Key Findings

• All eight API blueprints are registered in api/app.py
• GET route authentication behaviour appears inconsistent with older frontend/API documentation
• Several frontend pages lack proper error handling and may remain stuck in loading state if API calls fail
• frontend/API_ENDPOINTS.txt appears outdated in areas including port references, AI endpoint paths, demo/live mode description, and endpoint status
• API/database validation requires a configured PostgreSQL DATABASE_URL

Security

No secrets, JWT values, Azure credentials, database credentials, .env files, or local environment files were committed.

[parthrohit22]

Thanks for the updates. I re-reviewed the latest branch and the requested response-shape fixes look good now.

The validation guide now correctly documents the raw backend response shapes and clearly separates them from the frontend-normalized shapes for:

• GET /api/score
• GET /api/scans
• GET /api/drift
• GET /api/findings/:id/playbook

This makes the doc much more useful for future contributors because it explains both what the backend actually returns and what the frontend normalizers expose to components.

Also confirming the base-branch point: this PR targets dev. The larger 36-file diff only appears when comparing the branch against main, because dev already contains additional changes. Against the actual PR base, the diff is clean and limited to the validation docs.

For the scope of issue #132, this is a solid introductory validation framework. It documents the current state, known gaps, setup requirements, and follow-up validation work without trying to solve everything in one PR.

CI is green on the updated commit. Looks good to me.