Feature Requests: status badges, status filter, and a feedback CTA

Feature-request threads have carried an fr_status tag for a while (Approved, Rejected, Under Consideration, In Testing, Deployed), but the badges only rendered on the thread page. On the forum list at /forums/feature-requests, every request looked the same — no way to tell a live request from one that already shipped or was already rejected. That changes here.

Status badge on the thread list. Every feature-request thread with a set status now shows its status as a badge right before the title. The colors use the existing palette (green for deployed, red for rejected, blue for approved, amber for in-testing) so it reads as a status, not an alert. The one exception:

"Under Consideration" gets a loud inverse-video chip. This is the status where user feedback actually matters — the idea isn't decided yet and comments can still move the decision. To draw attention, it renders as a bordered inverse-video highlight with a subtle warm pulse, modeled on the CRT-phosphor aesthetic the site leans into elsewhere. Reduced-motion preferences are respected — the pulse disables and the chip stays static. No other status pulses.

"Add your take" CTA on open requests. Under every under_consideration, approved, or in_testing thread on the list, a small 💬 Add your take — feedback is open link now appears, pointing at the reply composer. Deployed and rejected threads don't get the CTA — those are closed; no point asking for more comments. Highlighting alone is passive; the CTA is the nudge that converts attention into comments.

Status filter chips at the top of the page. A chip row (All / Under Consideration / Approved / In Testing / Deployed / Rejected) now sits above the Hot/New/Top sort tabs on /forums/feature-requests. Clicking a chip narrows the list to that status; the active sort is preserved across chip changes, and the chosen filter is preserved across sort changes. "Under Consideration" chip renders in the same loud style as the badge so it reads as the call to action.

Admin setter already exists. The "Tag" button on any feature-request thread (visible to forum mods, category super mods, admins, and SysOps) already opens a modal that sets fr_priority / fr_type / fr_status / fr_effort via POST /thread/{id}/feature-tag. The action is audit-logged. No new admin UI needed for this change.

Implementation notes for anyone touching the code later:

• New helper class App\Helpers\FeatureRequestTags is the single source of truth for labels and badge CSS classes. Both templates/forums/show.php and templates/forums/thread.php pull from it — duplicate arrays that used to live in thread.php are gone.
• ForumThread::byForum() gained an optional ?string $frStatus parameter. When non-null, the query adds AND t.fr_status = :fr_status and the total count matches. The column exists on every thread, so passing a value on a non-FR forum is harmless (returns an empty result rather than erroring).
• ForumController::showForum() only honors ?fr_status= when the current forum slug is feature-requests. On any other forum the parameter is ignored silently so a stray query string doesn't blank a different page.
• .badge-fr-under-consideration is the new CSS class carrying the loud treatment — inverse-video colors driven by existing theme variables (--color-text-primary as background, --color-bg-card as foreground), so it adapts to the active theme (dark, light, CRT amber, C64, VT100) instead of hardcoded colors.

Try it: /forums/feature-requests. The MFA-email request sits at the top under its loud chip; four prior requests show their Deployed badges.