[Docs] Versioned documentation with mike (latest/stable selector)

Summary

The MkDocs site publishes a single rolling version from main. As the
project approaches Beta/1.0 with explicit stability promises, docs should
be versioned: a latest (development) and per-minor (0.14, 0.15, …)
selector via mike, so adopters on a released version read docs that
match their installed package.

Why this matters

• The stability page (docs/stability.md) makes compatibility promises
  per surface; those promises are hard to honor when docs always describe
  main.
• Rolling docs regularly document features that aren't on PyPI yet (the
  changelog's Unreleased section is substantial) — a classic source of
  adopter confusion and support load.
• Version selectors are an expected maturity signal for
  production-oriented Python libraries (mkdocs-material supports mike
  natively).

Proposed scope

• Add mike to the [docs] extra; configure extra.version.provider: mike in mkdocs.yml (mkdocs-material version selector).
• Update docs.yml workflow:
  • on push to main: mike deploy dev (alias latest configurable);
  • on release publish: mike deploy <major.minor> stable --update-aliases.
• Default URL serves stable; banner on dev noting it tracks main
  (mkdocs-material outdated/version banner).
• Document the scheme in CONTRIBUTING (when to backport doc fixes).
• One-time backfill: deploy current state as both the current minor and
  dev.

Implementation notes

• Workflow: .github/workflows/docs.yml currently builds and deploys to
  GitHub Pages directly; mike manages the gh-pages branch itself —
  migrate carefully to avoid clobbering existing pages (mike adopts the
  branch; do a dry run on a fork or with --push --remote off first).
• docs/gen_ref_pages.py (API reference generation) runs at build time —
  verify it behaves under mike's multi-version builds.
• Keep the version dropdown list short (stable, dev, plus 2–3 recent
  minors) by pruning old versions with mike delete policy documented.
• The README version drift check (scripts/check_readme_version.py)
  already enforces version consistency — extend it or document the
  release checklist step for docs deployment.

Acceptance criteria

• Docs site shows a version selector with at least stable and
  dev.
• Release workflow publishes versioned docs automatically on GitHub
  release.
• dev shows a banner that it documents unreleased changes.
• CONTRIBUTING documents the docs-versioning workflow.
• Existing URLs keep working (redirect or default alias).

Out of scope

• Backfilling docs for already-released historical versions.
• Hosting changes beyond GitHub Pages.

References

• mike: https://github.com/jimporter/mike
• mkdocs-material versioning guide:
  https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/
• Related: #324 (API stability visibility), docs/stability.md

Priority: P2 · Effort: M · Impact: Medium

Start with .github/workflows/docs.yml and mkdocs.yml, then inspect docs/gen_ref_pages.py and scripts/check_readme_version.py. Trace the current GitHub Pages deployment before evaluating mike's dev and release commands, including the existing URL behavior. Done means the selector, release publishing, dev banner, CONTRIBUTING guidance, and URL compatibility meet the acceptance criteria.