Publish documentation from `release` instead of `master`

[marcalexiei]

Problem

See #457 (comment)

Even after approval this PR should only be merged shortly before creating a new release. This avoid documenting a non-released feature, and also the usage of the new themes in our docs before they actually work. After the release I should check that the theming then works correctly in our docs.

Our user-facing documentation README.md and docs is published when it lands on master, but the code users hit is deployed from release.
That splits every documentation PR from the feature PR it belongs to:

• Prose describes features that aren't deployed yet.
• Sample cards are absolute URLs against https://github-stats-extended.vercel.app/api?...:
  the release deployment, so a doc PR adding a new theme renders broken cards until the next release promotion.

The practical cost is that documentation-affecting PRs can't be merged on approval;
they have to be held until shortly before a release, and re-checked afterwards.
Feature and bugfix PRs have no such problem.

Possible solutions

A: docs inside the frontend app

Serve the documentation as an MDX-rendered route in apps/frontend, deployed with the API from release.
Docs and API ship as one commit, so samples can use relative /api?... URLs and can't reference an unreleased theme.
SvgInline already runs the backend router in-browser over the bundled core, so samples could render without a network call at all.
It also works in local dev with no deployment.
Publishing release as latest and master as next would let contributors preview doc PRs before release, so they can be merged on approval.
Cost: we hand-build nav, sidebar, and search.

B: GitHub Pages built from release

A workflow renders docs/ to Pages on every push to release, so docs only publish alongside the deploy that satisfies them, doc PRs can be merged on approval and go live at the next promotion.
Docs live on a different origin, so samples stay absolute against the production host.
Benefit: smallest diff, no new build target, no Vercel routing change, and docs/ moves over as-is.

---

Either option requires demoting README.md to a stub (badges, short description, link to the docs site, contributing guide).
Otherwise the old manual keeps competing with the new one.