feat: enriched favorites list + Following→Favorite rename + shared BackButton (#437)

[fatherlinux]

Summary

Turns the My Valley "Following" list into the enriched "My List" view from #437, renames the feature to Favorite, and standardizes back buttons app-wide.

Favorites (#437)

• /api/favorites enriched with trail_status + news/upcoming-events counts (one LATERAL query, tz-whitelisted). New public GET /api/pois/summary?ids=&tz= batch endpoint gives anonymous favorites the same status/counts (local-first parity; mirrors the notification ?pois= precedent).
• Renamed Following → Favorite across UI + MyValley internals (backend favorites/user_poi_favorites unchanged). Favorites is now the first tab and default view.
• Rows: StatusBadge, green clickable name (opens POI on map), green 📰/📅 count chips, sort (recent/name/activity) + type-filter chips.
• Counts open that POI's news/events inside My Valley (reuses sidebar PoiNews/PoiEvents), and an item opens the article in-panel (ContentDetail) — focus never leaves the modal; identical on mobile + desktop.
• App router now resolves organization (virtual) POIs for /<slug>/<subtab> paths, so org favorites open the sidebar.

Shared BackButton

• New BackButton.jsx → every navigational back control reads "← Back" (action, not destination — fixes the misleading "Back to "). Swapped in ContentDetail, MyValley, News/EventPermalink, TripsManager, PrivacyPolicy; one .back-button style. My Valley keeps a single fixed back button across all detail levels.

Frontend + two additive backend endpoints. No DB changes. Spec/plan: .specify/specs/033-favorites-list/.

Closes #437

Test plan

• ./run.sh build passes
• Human-verified on :8083 — enrichment, rename, sort/filter, in-panel news/events/article, org favorites, fixed back button
• Gourmand clean
• Playwright smoke suite (CI / on deploy)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request implements the enriched favorites list and renames the 'Following' feature to 'Favorites' across the application. It introduces a new public batch enrichment endpoint /api/pois/summary for anonymous users, standardizes navigation with a new BackButton component, and updates the favorites tab to support sorting, filtering, and in-modal detail views. The reviewer feedback highlights critical issues in the backend: the timezone validation regex is too restrictive because it lacks hyphen support, which will break valid IANA timezones; the new /api/pois/summary endpoint is missing name and poi_roles fields required for anonymous user features; and applying AT TIME ZONE to the DATE column e.start_date can cause incorrect date shifts, which should be resolved by comparing the date directly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The /api/pois/summary endpoint is used to enrich anonymous favorites (stored in localStorage). However, it currently does not return p.name or p.poi_roles.\n\nBecause MyValley only receives destinations (point POIs) as a prop, any favorited linear features (trails/rivers) or virtual POIs (organizations) will fail to resolve their names in toRows and default to 'Saved place'. Furthermore, because poi_roles is missing, anonymous users will not be able to use the type-filtering or sorting features at all.\n\nIncluding p.name and p.poi_roles in the summary query solves both issues cleanly.\n\nAdditionally, e.start_date is of type DATE (without timezone). Applying AT TIME ZONE to a DATE converts it to a timestamp with time zone at midnight in that zone, and casting it back to ::date can shift the date by +/- 1 day depending on the database session's timezone setting. Comparing e.start_date directly to the timezone-adjusted current date is safer, simpler, and more correct.

    const summary = await pool.query(`
      SELECT p.id, p.name, p.poi_roles,
             ts.status AS trail_status,
             COALESCE(nc.cnt, 0)::int AS news_count,
             COALESCE(ec.cnt, 0)::int AS events_count
        FROM pois p
        LEFT JOIN LATERAL (
          SELECT status FROM trail_status
           WHERE poi_id = p.id ORDER BY created_at DESC LIMIT 1
        ) ts ON true
        LEFT JOIN LATERAL (
          SELECT COUNT(*) AS cnt FROM poi_news n
           WHERE n.poi_id = p.id
             AND n.moderation_status IN ('published', 'auto_approved')
        ) nc ON true
        LEFT JOIN LATERAL (
          SELECT COUNT(*) AS cnt FROM poi_events e
           WHERE e.poi_id = p.id
             AND e.moderation_status IN ('published', 'auto_approved')
             AND e.start_date >= (CURRENT_TIMESTAMP AT TIME ZONE $2)::date
        ) ec ON true
       WHERE p.id = ANY($1) AND p.deleted IS NOT TRUE`,
      [ids, tz]
    );

[gemini-code-assist]

The regex used to validate the timezone whitelisting is too restrictive because it does not allow hyphens (-). Hyphens are perfectly valid and common in IANA timezone names (e.g., America/Port-au-Prince, America/Blanc-Sablon, Africa/Porto-Novo, Asia/Ust-Nera). If a user's browser is in one of these timezones, the validation will fail and fallback to America/New_York.\n\nUpdating the regex to allow hyphens resolves this issue.

Suggested change

	const tz = (typeof rawTz === 'string' && /^[A-Za-z_]+\/[A-Za-z_]+(?:\/[A-Za-z_]+)?$/.test(rawTz))
	? rawTz
	: 'America/New_York';
	const tz = (typeof rawTz === 'string' && /^[A-Za-z_-]+\/[A-Za-z_-]+(?:\/[A-Za-z_-]+)?$/.test(rawTz))
	? rawTz
	: 'America/New_York';

[gemini-code-assist]

The regex used to validate the timezone whitelisting is too restrictive because it does not allow hyphens (-). Hyphens are perfectly valid and common in IANA timezone names (e.g., America/Port-au-Prince, America/Blanc-Sablon, Africa/Porto-Novo, Asia/Ust-Nera). If a user's browser is in one of these timezones, the validation will fail and fallback to America/New_York.\n\nUpdating the regex to allow hyphens resolves this issue.

Suggested change

	const tz = (typeof rawTz === 'string' && /^[A-Za-z_]+\/[A-Za-z_]+(?:\/[A-Za-z_]+)?$/.test(rawTz))
	? rawTz
	: 'America/New_York';
	const tz = (typeof rawTz === 'string' && /^[A-Za-z_-]+\/[A-Za-z_-]+(?:\/[A-Za-z_-]+)?$/.test(rawTz))
	? rawTz
	: 'America/New_York';

[gemini-code-assist]

e.start_date is of type DATE (without timezone). Applying AT TIME ZONE to a DATE converts it to a timestamp with time zone at midnight in that zone, and casting it back to ::date can shift the date by +/- 1 day depending on the database session's timezone setting. Comparing e.start_date directly to the timezone-adjusted current date is safer, simpler, and more correct.

      const favorites = await pool.query(
        `SELECT p.id, p.name, p.poi_roles, p.brief_description, p.has_primary_image,
                f.created_at AS favorited_at,
                ts.status AS trail_status,
                COALESCE(nc.cnt, 0)::int AS news_count,
                COALESCE(ec.cnt, 0)::int AS events_count
           FROM user_poi_favorites f
           JOIN pois p ON p.id = f.poi_id
           LEFT JOIN LATERAL (
             SELECT status FROM trail_status
              WHERE poi_id = p.id ORDER BY created_at DESC LIMIT 1
           ) ts ON true
           LEFT JOIN LATERAL (
             SELECT COUNT(*) AS cnt FROM poi_news n
              WHERE n.poi_id = p.id
                AND n.moderation_status IN ('published', 'auto_approved')
           ) nc ON true
           LEFT JOIN LATERAL (
             SELECT COUNT(*) AS cnt FROM poi_events e
              WHERE e.poi_id = p.id
                AND e.moderation_status IN ('published', 'auto_approved')
                AND e.start_date >= (CURRENT_TIMESTAMP AT TIME ZONE $2)::date
           ) ec ON true
          WHERE f.user_id = $1 AND p.deleted IS NOT TRUE
          ORDER BY f.created_at DESC`,
        [req.user.id, tz]
      );