Group top nav links into Discover/Account dropdowns

[zowskyy]

Summary

1. Nav cleanup — the signed-in top nav had grown to 14 flat top-level items. Grouped into two dropdowns:

• Discover ▾: Explore, Wander, Feed, Vibe, Rings
• Make, Notifications, Messages stay standalone (primary CTA / time-sensitive)
• Account ▾: My Page, Studio, Settings, Ask Us, Moderation (mods only), Policy, Log out

Signed-in desktop nav: 14 items → 5. New NavDropdown client component (click to open, closes on outside click/Escape/item activation, proper ARIA), styled to match the site's existing plain-border/monospace panels.

2. Full-codebase security/correctness audit — four parallel passes (social/messaging, moderation/safety, discovery/themes, API/infra) following up on earlier targeted fixes (#16, #17). Root-cause fixes for every confirmed finding:

Privacy/block-bypass leaks (same class as the earlier Top Eight and custom-CSS bugs, found in four more places):

• activityFeed.ts: a friend's activity leaked after they went private; guestbook-activity items exposed a private/hidden/blocked-from target's handle through a mutual friend's guestbook signature. Both now respect the same rules canViewPage enforces on a direct visit.
• proximityGraph.ts (Wander) and vibe/page.tsx (Vibe Graph): neither checked block relationships — a blocked user could still appear in Wander batches or the Vibe neighbor graph. Now excluded in both directions.
• collections.ts: curated collections used a narrower visibility filter than discovery's shared DISCOVERABLE_WHERE — a hidden-from-discovery or platform-blocked user's page still rendered on /explore/collection/[slug].

Race conditions (check-then-act without a transaction):

• stamps.ts, friends.ts, messages.ts — each had a window where concurrent requests could bypass a limit or crash on a constraint. All now atomic, matching the BEGIN IMMEDIATE pattern already used elsewhere in the codebase.

Idempotency:

• moderation.ts's reviewReport had no "already resolved" guard (unlike the equivalent appeals.ts path) — two moderators reviewing the same report could silently overwrite each other's outcome.

Missing rate limits:

• /api/visit, /api/presence: client-controlled tokens with no server-side cap allowed arbitrary count inflation.
• /api/status, /api/activity, /api/export, web ring join/leave: had no rate limit at all, unlike every comparable route.

Correctness:

• sharedThemes.ts: forking a theme never persisted forked_from_id/attribution_handle, despite every read path selecting and exposing them.

Hardening:

• handleParam.ts: a percent-encoded slash in the @handle route segment decoded to a value containing /, now rejected.

Added activityFeed.test.ts and collections.test.ts (neither had coverage before — how these leaks went unnoticed) plus regression tests for the moderation idempotency and theme-fork-attribution fixes.

Test plan

• npm test — 248/248 passing (10 new)
• npm run build — clean typecheck, all routes compile
• Nav verified live with a headless browser: logged-out/logged-in states, both dropdowns open/closed, correct conditional items

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}