[Parent] Public API exposes reviewer emails and allows bulk extraction

[jenul-ferdinand]

What

Tracking issue for five fixes that stop the public API leaking user data and make bulk extraction of reviews expensive and off-limits. Each fix has its own issue:

• Strip author PII from public review and profile reads #327 Strip author PII from public review and profile reads
• Cap popular-reviews count and admin-gate the all-units endpoint #328 Cap popular-reviews count and admin-gate the all-units endpoint
• Rate limit public read endpoints at the edge #329 Rate limit public read endpoints at the edge
• Add a no-scraping and copyright clause to the terms page #330 Add a no-scraping and copyright clause to the terms page
• Lock down infrastructure accounts #331 Lock down infrastructure accounts

Why

• GET /api/v2/reviews/popular?n=<large> returns every review with the author's full user document: email, googleID, admin flag, vote history and refresh-token hash. The route has no auth and no cap on n.
• The unit page requests populateReviewsAuthor=true (unit-overview.component.ts), so every visitor's browser downloads the email of every reviewer on that unit.
• GET /api/v2/units embeds every review for every unit in one response.
• GET /api/v2/users/:username strips tokens but returns email, admin and vote history. Usernames default to the first eight characters of the email.
• The backend has no rate limiting.
• The refresh-token hash is SHA-256 of a random token read from an httpOnly cookie, so an attacker cannot use it as a credential. It should not be public either.

Area

backend, frontend, infra, database

Notes or constraints

• Per-unit review reads stay public because that is the product. After the first two fixes, what is public matches what the site shows: review text, ratings, username and profile image.
• The first two fixes fit in one PR. The last one is dashboard work with no PR.