feat(frontend): rename profile to account and drop members from user dropdown

[NicholasKissel]

What?

In the user dropdown menu:

• Rename "Profile" → "Account"
• Remove the "Members" entry

Why?

Aligns the dropdown copy with the account-centric framing and trims the menu down to the entries that belong in this surface; members management lives in settings.

[NicholasKissel]

• feat(frontend): rename profile to account and drop members from user dropdown #5101 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[railway-app]

🚅 Deployed to the rivet-pr-5101 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	May 26, 2026 at 8:11 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	May 26, 2026 at 8:09 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	May 26, 2026 at 8:04 pm
ladle	✅ Success (View Logs)	Web	May 26, 2026 at 7:58 pm
mcp-hub	✅ Success (View Logs)	Web	May 26, 2026 at 7:57 pm
kitchen-sink	❌ Build Failed (View Logs)	Web	May 26, 2026 at 7:56 pm

[claude]

Code Review

Overview: Small, focused UI cleanup — renames the "Profile" menu item to "Account" and removes the "Members" entry from the user dropdown. Clean and well-scoped change.

Code Quality

• The unused faUsers import is correctly removed alongside the Members item. No dead imports left behind.
• The conditional {params.organization ? ... : null} guard is fully removed with the block, leaving no orphaned logic.
• Change is consistent with the surrounding code style.

Potential Issues

• Discoverability of Members: The Members entry was the only surface in the user dropdown that surfaced org member management. Users who relied on it as a shortcut will now need to navigate through Settings to find it. Worth confirming there's a clear path in the Settings UI so members management isn't buried.
• No feature flag gate: Given that CLAUDE.md recommends flagging significant panel/page/subsystem changes per deployment flavor, it's worth confirming this removal applies uniformly across cloud/OSS/enterprise flavors. If the Members item is only relevant to org-enabled flavors (it was already behind params.organization), removing it outright is fine, but the rationale should be that it's surfaced in Settings regardless of flavor.

Suggestions

• None on the code itself — the diff is minimal and correct.
• If there's a Settings → Members route that now covers this use case, a short follow-up to verify the Settings surface is reachable and labeled consistently with "Members" (not "Team" or "Users") would close the loop.

Summary

LGTM for merging. The code change is clean, the PR description explains the intent well, and the removed import is properly cleaned up. The only soft concern is discoverability of Members in Settings — confirm that path is clear before shipping.

[NicholasKissel]

Merge activity

• May 26, 8:44 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 26, 8:44 PM UTC: @NicholasKissel merged this pull request with Graphite.