Plugin reviews + ratings, with moderation (#167 Phase 3)

[dmccoystephenson]

Summary

Phase 3 of the community-profiles epic #167. Let signed-in users post a written review and a star rating on a plugin, so the catalogue surfaces community sentiment beyond raw bStats server counts and likes.

Scope

• Backend (dpc-api): a Review entity + table (owner = local User mirror, targetType/targetId keyed on the plugin id from plugins.json exactly like Like, a 1–5 rating, an optional body, timestamps; one review per user per plugin). Endpoints: authenticated POST/PATCH/DELETE /api/v1/reviews, public GET /api/v1/reviews?type=plugin&id=... (list) and an aggregate GET /api/v1/reviews/summary?type=plugin (avg rating + count per id), mirroring the existing LikeController shape.
• Moderation: a minimal first cut — a hidden flag on a review and an authenticated admin-only PATCH /api/v1/reviews/{id}/hidden. (Admin-role determination depends on the badges/roles work; until then, gate on a configured admin username list.)
• Frontend: a reviews section on the guide page (pages/guides/[id].tsx) and an average-rating chip on components/PluginCard.tsx; the author links to their public profile (/u/{username}, from Public profile pages — view another user's profile (#167 Phase 3) #181).

Why it matters

Ratings are the single strongest signal a server owner wants when choosing a plugin, and reviews give authors actionable feedback. This is the highest-value Phase 3 participation feature after likes.

Dependencies

• Builds on the likes model (same targetType/targetId keying) and the public profiles from Public profile pages — view another user's profile (#167 Phase 3) #181 (author attribution).
• Moderation roles overlap with the badges/roles issue; the configured-admin-list fallback keeps this shippable independently.

Filed as a Phase 3 decomposition of #167; drafted by Claude on behalf of Daniel Stephenson. Claims verified against Like/LikeController, User, and plugins.json.