Back-to-project links from side pages drop the active entity selection

[damienriehl]

Problem

useProjectHomeHref (lib/hooks/useProjectHomeHref.ts) routes side-page back-buttons to either /projects/{id} or /projects/{id}/editor based on the preferEditMode preference, but it does not carry the active class/property/individual selection through.

Used by:

• app/projects/[id]/analytics/page.tsx
• app/projects/[id]/pull-requests/page.tsx
• app/projects/[id]/settings/page.tsx
• app/projects/[id]/suggestions/page.tsx
• app/projects/[id]/suggestions/review/page.tsx

The viewer↔editor switcher (ViewerEditorSwitcher) carries selection correctly because it reads useSelectionStore and falls back to URL params. But the side-page back links call useProjectHomeHref directly, which builds a bare URL.

Why it matters

A user who is editing class :Foo, opens settings, then clicks "Back to project" lands on the project root with no selection — they have to navigate back to the entity manually. This was one of the motivating frustrations behind issue #98.

Proposed fix

Have useProjectHomeHref read the same selection store + URL fallback used by ViewerEditorSwitcher, and append the appropriate ?<type>Iri=… key.

Or: make useProjectHomeHref not return a bare string — return a hook-friendly object that callers can pass through <Link>-style helpers, with selection plumbed automatically.

Refs

• Surfaced during review of PR feat: preserve entity selection across viewer/editor modes #104 (closes Preserve entity selection across viewer/editor and unify continuous editing #98).
• Out of scope for Preserve entity selection across viewer/editor and unify continuous editing #98 itself, but a natural next step now that the URL plumbing exists.

[damienriehl]

Duplicate of #206, which covers the same concern with broader scope (selection + viewer/editor mode + active entity tab) and a more comprehensive sessionStorage-based last-URL approach. Closing in favor of #206.

Cross-linking: surfaced during review of PR #104.