add generalized builder filtering rail

[canicefavour]

Implemented builder filtering across the discovery experience by generalizing the existing filter rail architecture and extending it to support builder-specific facets without disrupting the existing Projects discovery flow.

Filter Rail Architecture

Refactored the existing filter-rail.tsx into a reusable, data-driven filter component that can support different discovery contexts through configurable sections, facet counts, and selection states.

The generalized architecture now handles:

Dynamic filter sections
Facet counts
Selected and unselected states
Generic checkbox interactions
Loading skeletons
Reset/clear functionality
Consistent label formatting for status values

This allows the same filter infrastructure to be reused across Projects and Builders instead of maintaining separate duplicated implementations.

Builder Filters

Added builder-specific filtering for:

Skills
Country
Status

Builder facet data is retrieved from the users filter endpoint and displayed dynamically with the corresponding result counts.

Supported builder status values include:

Available
Open to Work
Busy
Unavailable

Status values are formatted into user-friendly labels while preserving the API's canonical enum values.

Directory Filtering

Connected the builder filter state to the users directory API.

Filtering now supports:

Multiple selected skills
A selected country
A selected builder status

Changing a filter immediately updates the directory query and narrows the displayed builder results.

Pagination is also reset to Page 1 whenever the active filters change, preventing users from landing on an invalid or empty page after narrowing the result set.

URL & Reset State

Builder filters are synchronized with the URL search parameters, allowing filter state to remain consistent with the current discovery view.

The Reset/Clear functionality removes all active builder filters at once, including:

Skills
Country
Status
UI States

Builder filtering follows the existing Projects filter rail behavior for:

Loading states
Pending states
Error states
Skeleton placeholders
Empty/reset states

This keeps the discovery experience visually and behaviorally consistent across both sections.

Projects Regression Protection

The existing Projects discovery filter rail was preserved during the generalization work. The shared architecture continues to support the existing Projects filtering behavior without requiring a separate implementation.

Verification

Validated the implementation through:

Builder facet display and dynamic counts
Skills, country, and status filtering
URL filter synchronization
Pagination reset behavior
Complete filter reset functionality
Projects discovery regression checks
TypeScript validation
Linting
Production build verification
Result

The discovery system now provides a reusable filtering architecture capable of supporting both Projects and Builders. Builders can be filtered by relevant profile facets while maintaining consistent UX, URL state, pagination behavior, and loading/error handling across the discovery experience.

Closes #366

[vercel]

Someone is attempting to deploy a commit to the Threadflow Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@canicefavour Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Benjtalkshow]

Thanks! eslint passes, but npx tsc --noEmit fails with 6 errors, so the build cannot pass.

1. builders-filter-rail.tsx:33 make BuilderFilterValue a type, not an interface. An interface has no index signature.
2. page.tsx:51,149,156 Button has no variant prop. Use intent and appearance.
3. page.tsx:144 pagination hides on a short last page and traps the reader.
4. Please reuse BuilderCard, and drop IMPLEMENTATION.md and .vscode.

Add a screenshot.

[Benjtalkshow]

@canicefavour
Whats up with this PR?

[canicefavour]

Working on it

[Benjtalkshow]

Thanks for the work here, and sorry it got overtaken. The shared filter rail landed in #371 while this was open, so most of what is here now exists on main in another form. That is a sequencing failure on our side, not yours. The foundation issue should have merged before any of the dependent issues were handed out.

Merging this so your work is recorded. I will follow up straight after with a cleanup that removes the duplicated rail, sheet and API layer, so the tree keeps one copy of each. Nothing you did wrong, just two implementations of the same thing arriving at once.