fix(back-button): require same-origin referrer before stepping browser history, so fresh-tab Back falls back to the in-app route

[pandadev66]

Summary

The shared BackButton component used on every detail page (Miner, Repository, PR, Issue, Search) decides whether to step the browser history or fall back to a known in-app route based solely on window.history.length > 1. That check isn't a reliable signal that the previous history entry actually belongs to the app — opening a detail page directly in a fresh tab, from a bookmark, or by clicking a shared link from outside the app all leave a non-app entry as the "previous" page, so clicking "Back" calls navigate(-1) and the user is taken out of the app.

This PR tightens the check with the same approach used for the 404 page: require document.referrer to share the app's origin before stepping back. When the previous entry can't be confirmed in-app, the button falls through to the per-page to route (e.g. /top-miners from a miner profile, /repositories from a repo page) that the component already accepts as a fallback.

Behavior

• Navigated in from another app page (history.length > 1 AND same-origin referrer) → navigate(-1) — unchanged from today.
• Router state carries an explicit backTo (set by list pages when they link into a detail page, e.g. "Back to Watchlist") → navigate(state.backTo) — unchanged.
• Fresh tab / bookmark / external link (no referrer or cross-origin referrer) → navigate(to) — the page-specific in-app fallback the component already takes as a prop. Previously this fell through to navigate(-1) and left the app.

Verification

1. Open /miners/details?githubId=<known-id> directly in a brand-new tab (paste the URL into the address bar, or click a link to it from a non-app origin). Click "Back" once — the app should land on /top-miners rather than the browser's previous tab/page.
2. Repeat for the other detail pages by opening them the same way: /miners/repository?name=… → /repositories, /miners/pr?repo=…&number=… → /repositories, /bounties/details?id=… → /bounties.
3. Navigate normally from a list page to a detail page (e.g. click a row on /top-miners). The "Back" button should still call navigate(-1) and return to the exact list state, including any filters or scroll the page restores from router state.
4. Set an explicit backTo in router state (e.g. "Back to Watchlist") and confirm the button still routes to that destination when the in-app history signal isn't trusted.

Why this approach

• One small change to a shared component fixes the symptom on every page that consumes it; no per-page changes needed.
• Mirrors the same-origin referrer check that's already been deployed on the 404 page's own "Go back" button, so the two surfaces behave consistently.
• The to prop already exists on every caller (it's required), so there's no new copy or routing config to keep in sync — the fix uses what's already there.

Recording

84.mp4

Fixes #1162

[pandadev66]

@anderdc Could you take a look when you have a moment? Thanks!