Expose missing member profile data for redesigned profile page

Context

The redesigned member profile concept includes public profile metadata and modules that the current API cannot supply. The web migration should not derive or invent these values.

Missing data

• Public join date for profiles other than the current member
• Optional member bio and location fields
• Follower/following totals if the Friends model should be presented as follows
• Distinct distillery count for a member tasting record
• Passport/coverage summaries backed by real tracked-object membership
• A paginated contributions list for the proposed Contributions tab

Existing coverage

The current users details, tasting stats, region list, tasting list, and library endpoints already cover identity, privacy/friend state, tasting and bottle totals, library totals, contribution count, verdict distribution, and regional tasting counts.

Web behavior until this lands

The profile page will show only API-owned values. It will omit unsupported metadata and modules rather than substitute badge levels, infer history, or fabricate counts.

Start by tracing the existing users details, tasting stats, region, tasting, and library endpoints mentioned in the issue to understand their coverage and conventions. Identify where each missing profile value belongs, including real tracked-object membership and pagination, and consider the work done when the API exposes supported data without inferred or fabricated values.