EDU-16758: fix API reference endpoint deep links rendering as overview

[PedroAntunesCosta]

Fixes a regression introduced by PR #1226 (feat/api-reference-seo-indexing) where every deep link to an API reference endpoint — e.g. /docs/api-reference/foo#get--endpoint — rendered the overview page instead of the interactive RapiDoc endpoint view.

Changes

• Track the URL hash via a clientHash state populated from window.location.hash on mount and on hashchange, replacing the previous router.asPath-only detection.
• Fall back to the existing router.asPath parsing when the client hash is empty, preserving the legacy ?endpoint= behavior.

Why

The SEO indexing PR introduced conditional rendering between the SSR-friendly overview HTML and the client-only RapiDoc element, gated by isOverview = endpointPath === slug. That flag was derived from router.asPath, but Next.js does not include the URL hash in asPath during SSR or on the initial client hydration of a directly-loaded URL. As a result, any direct link with a hash hydrated as the overview and never re-rendered into the endpoint view. Reading window.location.hash after mount restores the previous behavior without changing the SSR output.

Notes

• SSR output is unchanged: useState('') produces the same overview HTML the server already rendered, so the SEO improvements from EDU-16758: Improve API reference SEO and indexing #1226 are preserved.
• In-page table clicks and back/forward navigation still work via the existing hashchange listener, which now also feeds clientHash.

Related Task

EDU-16758

[netlify]

❌ Deploy Preview for elated-hoover-5c29bf failed. Why did it fail? →

Name	Link
🔨 Latest commit	8825c7e
🔍 Latest deploy log	https://app.netlify.com/projects/elated-hoover-5c29bf/deploys/6a067baa9ef8340008f6c348

[github-actions]

All tests were successful!

[PedroAntunesCosta]

Closing this PR — it has been superseded by #1264.

Why

This PR's branch (fix/api-reference-endpoint-hash-routing) is based on main as it was immediately after PR #1226 merged. While this PR was open, a separate Netlify deploy issue surfaced (every preview deploy off post-#1226 main started failing AWS Lambda's CreateFunction with HTTP 400 starting around May 14 16:21 UTC). PR #1226 was reverted via #1262 to unblock production, which made this branch's base disappear from main and left this PR stranded — its deploy preview would still fail because the base build state still includes PR #1226's content via the cherry-picked merge.

PR #1264 re-lands PR #1226 + this PR's hash-detection fix as a single branch off post-revert main, plus the one concession needed to get past Netlify's Lambda step:

• Re-applied PR EDU-16758: Improve API reference SEO and indexing #1226 byte-for-byte (commit f2b260c5).
• Cherry-picked this PR's commit 8825c7ef (the clientHash from window.location fix) — commit 5b96d203 on chore: reland PR #1226 + PR #1261 — Netlify deploy probe #1264.
• Dropped revalidate: 86400 from getStaticProps (commit a734b2ce). This shaves ~35 MB off each Next.js handler bundle (the ISR-prerendered cache data Next.js was inlining), which is enough to clear whatever Lambda parameter threshold AWS started enforcing on May 14.

The deploy preview on #1264 is green: https://deploy-preview-1264--elated-hoover-5c29bf.netlify.app

What was actually wrong

Postmortem TL;DR: this PR's hash fix and the Netlify deploy failure are causally unrelated — the deploy issue first manifested on PR #1260 (a navigation JSON edit) hours before this PR was opened, and the trigger appears to be a Netlify/AWS infra-side tightening rather than anything in this branch.

The hash-detection fix you wrote here is shipping verbatim in #1264. Nothing about your code was the problem.